This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Program Breakpoints

On Tuesday 24 March 2009 20:39:53, Daniel Jacobowitz wrote:
> No, I was saying the opposite. ?Sometimes it will still be expensive
> to implement the protocol extension. ?I'm interested in whether anyone
> sees an approach that does not require instruction scanning.

[ For the record, since I was curious about the  win32 bits below ]

Several OSs already export that info on their debug APIs, but we
just discard it.

Some linux archs expose it in the SIGTRAP siginfo, in
the si_code field, in the form of TRAP_BRKPT, TRAP_TRACE.  E.g., I think
ppc does expose TRAP_BRKPT, but x86/x86_64 doesn't, at least not yet.

I believe mac/darwin also distinguishes breakpoint traps from
single-stepping traps at the debug api level.  At least include/gdb/signals.h
mentions TARGET_EXC_BREAKPOINT as being a Mach exception.  This could
mean that GNU/Hurd also distinguishes them.

Windows distinguishes breakpoints from singlesteps at the debug API level
see that windows-nat.c converts both to SIGTRAP.  I've just confirmed this,
by enabling "set debugexceptions on" on a Cygwin GDB.

Probably other os/archs/targets have similar means to distinguish a
breakpoint trap from a singlestep.  Either through a different trap
vector for each case, or looking at the trace flag and at the intruction
stream themselves, etc.

Pedro Alves

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]