qemu-devel
[Top][All Lists]
Advanced

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

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


From: Lucien Anti-Spam
Subject: Re: [Qemu-devel] m68k gdb has stopped single stepping correctly
Date: Thu, 24 Jan 2019 12:59:54 +0000 (UTC)

 

   > 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?
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

  

reply via email to

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