Re: RFC: Program Breakpoints

[Mark Kettenis <mark.kettenis@xs4all.nl>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Tue, 24 Mar 2009 23:48:21 +0000
> 
> 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
> too.  We have EXCEPTION_SINGLE_STEP and EXCEPTION_BREAKPOINT.  You'll
> 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.

These statements are all rather i386-centric.  Especially on targets
that emulate single-stepping it may be impossible to distinguish.  GDB
should not depend on the ability to do so.