From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24298 invoked by alias); 25 Mar 2009 07:58:59 -0000 Received: (qmail 24287 invoked by uid 22791); 25 Mar 2009 07:58:58 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Mar 2009 07:58:52 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id n2P7vRSS011457; Wed, 25 Mar 2009 08:57:27 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id n2P7vQod004081; Wed, 25 Mar 2009 08:57:26 +0100 (CET) Date: Wed, 25 Mar 2009 07:58:00 -0000 Message-Id: <200903250757.n2P7vQod004081@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: pedro@codesourcery.com CC: gdb@sourceware.org, drow@false.org, ross@tensilica.com In-reply-to: <200903242348.22395.pedro@codesourcery.com> (message from Pedro Alves on Tue, 24 Mar 2009 23:48:21 +0000) Subject: Re: RFC: Program Breakpoints References: <49C94379.3020206@tensilica.com> <20090324203953.GA309@caradoc.them.org> <200903242348.22395.pedro@codesourcery.com> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-03/txt/msg00151.txt.bz2 > From: Pedro Alves > 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.