> On Thursday, January 24, 2019, 3:08:07 AM GMT+9, Emilio G. Cota <c...@braap.org> 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? 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? What do people think, what would be the right approach to this?
Cheers,Luc
