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] |
I've had some time to refine my break/watchpoint extensions, and have come up with this revised proposal. Request Packet insert break B<type>,<address>[,<length>] reply OK for success. ENN for an error. remove break D<type>,<address>[,<length>] reply OK for success. ENN for an error. In my earlier proposal, if the 'B' command successfully inserted a breakpoint, it returned a integer cookie uniquely identifying that breakpoint. The 'D' command used the cookies to remove breakpoints. I have changed 'D' to specify breakpoints in the same manner as they are inserted. This was done because GDB internally represents break/watchpoints by type/address/length. It would require additional hair in both GDB's remote.c and the stub to index breakpoints by a cookie. In light of this, there is no compelling reason to use a cookie. I also proposed using the characters 'r', 'w', and 'x' for <type> (indicating read, write and execute breakpoints), but I now think <type> should be an integer. I found that there are at least 5 types that need to be supported. And although I can't think of any more off hand, there may be more. A numeric <type> is a bit easier to parse in the stub, and although the 'r', 'w', 'x' mnemonic is nice, it's likely to break down as new types are added. Since the remote protocol is primarily for machine/machine communication, an integer is sufficient. There was one type defined for execution breakpoints, but I've decided that separate types to indicate software and hardware breakpoints are required. It's unrealistic to assume that the stub can make the decision whether to use a hard- or soft- breakpoint as well as the programmer driving GDB. I've also discovered that GDB currently supports read, write, and read/write (access) watchpoints. My current definition for <type> is: 0 software breakpoint 1 hardware breakpoint 2 write watchpoint 3 read watchpoint 4 read/write (access) watchpoint It so happens that the <type>s used for watchpoints are the same as the the TYPE argument to target_{insert,remove}_watchpoint + 2. Thoughts? I'd like to get the protocol nailed down so I don't have to change it after I roll it out within RedBack. --jtc -- J.T. Conklin RedBack Networks