Re: gdbstub initial code, v8

[Oleg Nesterov <oleg at redhat dot com>]

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.