[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