This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> > Here is the protocol elements that I'm currently working with: > > > > Insert Breakpoint: B<type>,<address>[,<length>] > > returns: ?? - A cookie representing the breakpoint > > EX - breakpoint type not supported > > - no breakpoint contexts available > > - invalid/unsupported address > > - invalid/unsupported length > > FYI, there is already a semi-official use of `B' as a generic remote > breakpoint operation. The syntax is: > > B<address>,S Set a breakpoint > B<address>,C Clear a breakpoint > > When using this, GDB assumes the target can handle all breakpoints. Umm... I checked the current (98/11/21) GDB snapshot's remote.c, all of the sample stubs, and remote.texi and could find no evidence of a breakpoint command, much less a 'semi-official' one. So I went back to a design Stu described to me some years ago as the foundation of my current work. I think the refined proposal I sent to the list yesterday is far superior to the the one described above, as that would require yet another set of commands for hardware break/watchpoints. > With regard to the general question of extending the remote-gdb protocol > so that it supports a generic hardware breakpoint mechanism. I agree it > is needed. It is a missing part of the overall toolkit. > Did you know that some targets actually implement hardware > breakpoints by poking the registers directly? I saw that. Yuck. --jtc