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