gdbstub initial code, v8

Oleg Nesterov oleg at redhat.com
Mon Sep 6 20:44:46 UTC 2010


On 09/06, Jan Kratochvil wrote:
>
> On Mon, 06 Sep 2010 20:18:08 +0200, Oleg Nesterov wrote:
> > On 09/05, Jan Kratochvil wrote:
> >
> > > (also to put in breakpoints):
> >
> > And this is not clear to me, I need your help ;)
>
> Sorry, I just meant that by implementing the memory writes breakpoints
> automatically start to work.
>
>
> > What should ugdb know about breakpoints? I played with the real
> > gdbserver, and afaics gdb just changes the tracee's memory and
> > inserts 0xcc (int 3). But gdb.info mentions "Z TYPE,ADDR,KIND"
> > packets.
>
> I believe it is described by:
>   /* If GDB wanted this thread to single step, we always want to
>      report the SIGTRAP, and let GDB handle it.  Watchpoints should
>      always be reported.  So should signals we can't explain.  A
>      SIGTRAP we can't explain could be a GDB breakpoint --- we may or
>      not support Z0 breakpoints.  If we do, we're be able to handle
>      GDB breakpoints on top of internal breakpoints, by handling the
>      internal breakpoint and still reporting the event to GDB.  If we
>      don't, we're out of luck, GDB won't see the breakpoint hit.  */
>
>
> > So, what should ugdb do? Just implement memory write (M or X)
> > and then report SIGTRAP like gdbserver does?
>
> Therefore until you track some ugdb-specific software(*) breakpoints ugdb does
> not need to support Z0 IMO.  I guess ugdb will never have to support these:
> thread-related(?) and tracepoint ones.

Good! I thought ugdb should somehow handle this all "transparently"
for gdb. I thought (I don't know why) that writing "int 3" from gdb
side should be avoided in favour of some "better" method unknown to me.

Thanks Jan.

Oleg.




More information about the utrace-devel mailing list