Re: [Qemu-devel] m68k gdb has stopped single stepping correctly

[Alex Bennée]

Lucien Anti-Spam via Qemu-devel <address@hidden> writes:

>
>
>    > On Thursday, January 24, 2019, 3:08:07 AM GMT+9, Emilio G. Cota 
> <address@hidden> wrote: > > On Wed, Jan 23, 2019 at 15:58:27 +0000, Lucien 
> Anti-Spam via Qemu-devel wrote:> > Hi folks,
>> > I noticed that with 3.x release that the GDB options (-S -s) for certain 
>> > CPU results in very weird stepping.Usually stops afer a few steps, whilst 
>> > the stub continues responding the PC doesnt update, however, I have only 
>> > deeply looked at the m68k.
>> > In the case of the m68K the SR gets the trace bit set (T=10b), and the PC 
>> > doesnt update.The m68k gdbstub, and main gdbstub seem mostly unchanged.But 
>> > it seems the INSN handling has changed greatly for the m68k.
>> > Does anyone have any ideas what happened?>> Can you please bisect to find 
>> > at which point things start misbehaving?
>>
>> Thanks,
>>  Emilio
> Understood, I was hoping my original post might jog someone's memory about 
> the issue.
> Apparently not, so after some digging I found that it was introduced with the 
> refactor to TranslatorOps, specifically two lines got dropped that update the 
> PC if single-stepping is being performed ( commit 
> 11ab74b01e0a8ea4973eed89c6b90fa6e4fb9fb6 )
> Since its not valid to revert, shall I go ahead and submit a patch for
> these two lines?

Yes please!

> Also I noticed a lack of gdb-stub tests, but there are cpu tests (eg. 
> check-qtest-m68k).  I was considering it might be interesting to write some 
> basic network code to send / receive gdb packets to re-use these cpu tests 
> for step, break-point, register update, and so on.
> I saw a gdb-python test but I felt this would need specific kernel \
> gdb for each cpu with is likely to end in a lot of problems getting
> right gdbs - simple packet send/receive/check would be better?

The gdb-python test works should work with pretty much any kernel image
but is currently only run manually. It only really sets breakpoints at
common points in the kernel and doesn't need a rootfs to complete.

So it's useful for bisecting but it would be nice to have proper
integrated tests. I basically submitted it so it wouldn't just languish
in my own magic directory of random tests.

> What do people think, what would be the right approach to this?

Once thing we have now is tests/tcg and the infrastructure for building
foreign binaries on most developer systems. We can certainly leverage
those to have a nice test binary which we can use to exercise gdbstub
for linux-user debugging with the appropriate wrapping of gdb and
launching a guest.

There is also a WIP series I posted:

  Subject: [RFC PATCH  00/13] Enabling tcg/tests for xtensa, mips and cris
  Date: Mon, 10 Dec 2018 15:28:16 +0000
  Message-Id: <address@hidden>

Which makes the tests/tcg infrastructure aware of softmmu targets (used
for system emulation). We could certainly build a mini-stub of an OS
using this to exercise the system gdbstub. You could just use the
existing binaries we use for migration testing although it would be nice
to have them in source form as well.

You might want to look at the avocado tests - they may be better suited
for coordinating several binaries talking to each other (although the
existing qtest tests do do something similar).

>
> Cheers,Luc
>
>


--
Alex Bennée