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.