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 been tasked to add support for hardware watch/breakpoints over the remote protocol. This is what I'm thinking so far: A create breakpoint command would insert a breakpoint insn or set the appropriate debug registers. A cooresponding delete breakpoint command would remove a breakpoint. Having stubs manage their own breakpoints may even be adventageous for systems without hardware breakpoints. As GDB inserts breakpoint insns directly in the text segment, it requires the text segment to be read/ write. Errors that would ordinarily cause an exception could pass unnoticed. The mem write command could be modified to write enable the page, copy the data, and then write protect it again; but doing those protection modifications only when breakpoints are inserted and removed protects the user from inadvertantly using GDB to modify read only data. This of course, would require the stubs to keep track of more information. In many cases allocating breakpoint contexts dynamically would be impossible or undesirable (it is likely that you couldn't use the same dynamic memory allocator as the rest of the system (if indeed such a facility was available) as it wouldn't be safe to use in an interrupt/exception context). As such, the protocol will have to have a mechanism to indicate that all available breakpoints have been allocated. This is probably not much of a concern, since ROM monitors and hardware watch/breakpoint registers have similar constraints. I'd like to not limit the number of contexts to a fixed number, as some systems/debugging situations may need many more than others. 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 Remove Breakpoint: D<cookie> returns: OK - breakpoint removed EX - breakpoint <cookie> not found <type> 'r', 'w', 'x' for read, write, or execute. <address> A target address <length> 1, 2, or 4; number of bytes for read or write watchpoint. When the target is started (step, continue), the stub is responsible for installing breakpoints instructions. Likewise, when the stub regains control, it is responsible for removing breakpoints. --jtc