qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Weird qemu behaviour with Freescale Coldfire MCF5282


From: Thomas Huth
Subject: Re: [Qemu-discuss] Weird qemu behaviour with Freescale Coldfire MCF5282
Date: Thu, 31 Jan 2019 08:00:14 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 2019-01-30 17:59, Alessandro Carminati wrote:
> From: Thomas Huth <address@hidden>
[...]
> Thank you for your explanation. It helps me a lot in comprehending how Qemu 
> works, and also understand some of the behavior I see in the logs.
> Using GDB was my first choice, I tried this way before the log. It is 
> supposed to be interactive, therefore more comfortable than  reading a giga 
> log. But when I tried it, on the m68k architecture, I couldn't make it work. 
> To say it better, I was able to set breakpoints and start the execution, but 
> the single step didn't work in my case. In the past, I used Qemu-GDB solution 
> with ARM architecture with no problem, so I assumed I just stepped into m68k  
> implementation problem and switched on the backup solution. Is there anything 
> else I should know on the  "target remote" GDB "s" and "si" commands to work 
> on the m68k implementation? When I issue the command, the GDB interface 
> reports no error, but the target CPU state does not change.

That rings a bell, I think this is the problem that has been reported to
the qemu-devel mailing list some days ago:

 https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg06241.html

The problem has been introduced with QEMU v3.0 ... so as long as it is
not fixed yet, maybe you could try v2.12 to see whether single-stepping
works there for you?

 Thomas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]