From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5613 invoked by alias); 24 Mar 2009 23:48:16 -0000 Received: (qmail 5604 invoked by uid 22791); 24 Mar 2009 23:48:15 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Mar 2009 23:48:11 +0000 Received: (qmail 24788 invoked from network); 24 Mar 2009 23:48:09 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 Mar 2009 23:48:09 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: RFC: Program Breakpoints Date: Tue, 24 Mar 2009 23:48:00 -0000 User-Agent: KMail/1.9.10 Cc: Daniel Jacobowitz , Ross Morley References: <49C94379.3020206@tensilica.com> <20090324203953.GA309@caradoc.them.org> In-Reply-To: <20090324203953.GA309@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903242348.22395.pedro@codesourcery.com> X-IsSubscribed: yes 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/msg00148.txt.bz2 On Tuesday 24 March 2009 20:39:53, Daniel Jacobowitz wrote: > No, I was saying the opposite. =A0Sometimes it will still be expensive > to implement the protocol extension. =A0I'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. --=20 Pedro Alves