This is the mail archive of the
mailing list for the Archer project.
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"
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.