[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qemu-discuss
Subject:    Re: [Qemu-discuss] Weird qemu behaviour with Freescale Coldfire MCF5282
From:       Thomas Huth <huth () tuxfamily ! org>
Date:       2019-01-31 7:00:14
Message-ID: 298f050e-8717-26c7-ed10-e705747fc56e () tuxfamily ! org
[Download RAW message or body]

On 2019-01-30 17:59, Alessandro Carminati wrote:
> From: Thomas Huth <thuth@redhat.com>
[...]
> 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


[prev in list] [next in list] [prev in thread] [next in thread]