This is the mail archive of the
mailing list for the Archer project.
Re: gdbstub initial code, v8
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.