Hello, I was able to run the regressions on x86 linux native, and fixed a problem. I've also incorporated Eli's feedback on the doc and NEWS (maybe I went a bit verbose on the NEWS, but you can tell me what to cut). I kept using the term "target" in the remote protocol section because it's common there. New patch attached, replaces previous. Awaiting technical review. I am least confident about my merge with non-stop thread support, though it causes no new test failures on x86 linux native. Thanks, Ross -- Ross Morley ross@tensilica.com ross@computer.org Ross Morley wrote: > Sorry, there was a minor technical glitch with the patch. Fixed patch > attached. > > -------- Original Message -------- > Subject: [PATCH] Program Breakpoints > Date: Fri, 17 Apr 2009 18:32:59 -0700 > From: Ross Morley > To: GDB Patches > CC: Maxim Grigoriev > > > > Hello GDB reviewers, > > This is the result of the RFC discussion on the GDB list late March. > I have simplified and updated the feature as discussed. In addition > I have supported it in gdbserver (only the Xtensa target so far). > In gdb and gdbserver, target support is optional, and targets that > do not support it behave as before. User guide updates are included. > > *** A patch is submitted for your review (attached). *** > > A detailed discussion follows... > > A "program breakpoint" is a trap instruction inherent to the target > program and unknown to GDB. It is like a permanent breakpoint except: > - it is unknown to GDB (not in the breakpoint table). > - it need not be the same instruction used by GDB for breakpoints. > > Here is the current behavior this patch fixes: > > GDB cannot distinguish a SIGTRAP due to a trap instruction in the > program from one due to single stepping (or other reasons). Breakpoints > are recognized only if they are known to (and usually planted by) GDB. > A trap instruction inherent in the target program is not recognized. > If the target hits one during normal run, GDB receives a SIGTRAP and > sees it as a random signal, reports SIGTRAP and (fortuituously) stops. > If this happens during stepping, GDB assumes the SIGTRAP is from a > single-step and keeps going, repeatedly hitting the trap. A user using > software watchpoints expects slow exection, so may wait a long time > before suspecting a problem, only to find out GDB is hung. > > Here's a description of the feature and the reasons for it: > > A new target.h macro is provided to allow GDB to determine that it > was stopped by a trap instruction: STOPPED_BY_TRAP_INSTRUCTION(size). > The optional size parameter is a pointer into which the size of the > instruction is written if the PC is pointing to it, allowing GDB to > skip it on resume or step. Targets that implement this recognize > program breakpoints by knowing they hit a trap that is not in the > breakpoint table. A GDB planted breakpoint always takes precedence > over a program breakpoint (in fact GDB might plant a breakpoint > over a program breakpoint). I have only implemented it for the > (remote) targets we support. > > Any target may implement this macro, receiving information from the > inferior or probing the instruction in memory, as appropriate. For > remote targets it is usually much more efficient to have the target > communicate that it hit a trap instruction (especially since some > targets may modify the PC to back out of an exception handler the > trap is used in, leaving GDB no way to know directly). > > Remote targets may notify GDB of hitting a trap instruction by an > extension to the stop-reply packet for SIGTRAP: "TAAtrap:r", where > r is a single digit representing the size of the trap instruction > if and only if the PC is pointing to it (it needs to be skipped). > That result is passed to infrun and infcmd via the macro above. > Note that the remote target is not expected to distinguish a > program breakpoint from a GDB-planted software breakpoint (that > distinction is made in infrun by looking up the breakpoint table). > > When GDB detects a program breakpoint (even while stepping) it > stops and reports it to both CLI and MI. When stopped by one (and > if the PC has not been altered while stopped), on resume or step > GDB will step over it by incrementing the PC by the size (if != 0). > In the case of step-instruction where PC points to the trap, the > first step does not actually run the inferior but merely increments > the PC, simulating the expected advance of 1 instruction. > > gdbserver has been modified to recognize a trap as distinct from > a single step, and pass the information from the low target up > to the remote interface. The target must support this for the > information to be passed to GDB via the stop-reply extension. > > This has been implemented and well tested in Xtensa toolchains > with the Xtensa instruction set simulator as the target agent. > It has now also been tested with gdbserver on Xtensa. No other > targets yet implement this. > > The user manual has been updated. I will update the internals > manual after this patch has been (possibly changed and) accepted. > > We have a target specific regression test internally. However I > don't know how to make a generic test case because it needs to > embed an arch-specific trap instruction with an __asm__ construct. > Advice on this would be appreciated. We could submit the test as > a target or arch specific test. > > In merging from our GDB 6.8 based internal source base (on which > our extensive testing was done) to the CVS head, I had to merge > with non-stop thread support and reverse debugging. I believe > I have handled those correctly, but have no target to test them > on. I hope someone can integrate this patch and run all the > regressions to make sure I didn't break anything. > > Thanks and best regards, > Ross > > -- > Ross Morley > ross@tensilica.com > ross@computer.org > >