From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J.T. Conklin" To: gdb@cygnus.com Subject: breakpoint extension for remote protocol, take II Date: Thu, 10 Dec 1998 17:51:00 -0000 Message-id: <199812110150.RAA21699@jtc.redbacknetworks.com> X-SW-Source: 1998/msg00187.html I've had some time to refine my break/watchpoint extensions, and have come up with this revised proposal. Request Packet insert break B,
[,] reply OK for success. ENN for an error. remove break D,
[,] 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 (indicating read, write and execute breakpoints), but I now think 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 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 is: 0 software breakpoint 1 hardware breakpoint 2 write watchpoint 3 read watchpoint 4 read/write (access) watchpoint It so happens that the 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