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] |
> > 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 > > Where is this used? I see no evidence of this in devo's remote.c. > Is it hiding out on a branch somewhere? FYI, the syntax is bogus. > It should use B and b like the rest of the commands. Although I noticed the parallelism of the existing commands g/G, m/M, and I recently proposed p to compliment P; I used B/D instead of b/B because inserting and removing breakpoints don't have quite the same type of symmetry as reading and writing memory or registers. A read command doesn't change the state of the target, while removing a breakpoint certainly does. One issue with 'b' is that it's used in the sparc* stubs to set the baud rate of the connection. That code has been #ifdef'd out with the comment "Disabled until we can unscrew this properly", so we may be able to simply junk that. Nevertheless if it is thought that b/B should be used, I'll make that change. I could roll out breakpoint support within RedBack tomorrow, but that would be less than optimal if I had to deal with supporting multiple versions of GDB for different releases of our software. It's in my interest to get the protocol extensions nailed down and agreed upon before I deploy it (and get it contributed). > > 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. > > I have discussed this with GDB folk in the past. If you want to hear what > needs to be done, ping me. Stu, I think I implemented your design faithfully. However, it was from memory of a two year old conversation. If I've left something out, please let me know. > > Did you know > > that some targets actually implement hardware breakpoints by poking the > > registers directly? > > Yes, and this is a complete sin. A related sin which needs to be addressed is that there can be only one set of hardware watchpoint and breakpoint functions (ie. they're not in the target vector). Now that the remote protocol can support hardware break/watchpoints, we'll need to fix that. --jtc