This is the mail archive of the archer@sourceware.org mailing list for the Archer project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdbstub initial code, v8


On Mon, 06 Sep 2010 20:18:08 +0200, Oleg Nesterov wrote:
> On 09/05, Jan Kratochvil wrote:
> > On Sat, 04 Sep 2010 00:40:47 +0200, Oleg Nesterov wrote:
> > memory writes
> 
> Yes. This is simple.
> 
> > (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.

(*) That is the memory-type one.  There are also `hbreak' breakpoints via the
    CPU debug registers.


Thanks,
Jan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]