From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4524 invoked by alias); 4 May 2009 22:49:24 -0000 Received: (qmail 4515 invoked by uid 22791); 4 May 2009 22:49:23 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hq2.tensilica.com (HELO maia.hq.tensilica.com) (65.205.227.30) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 04 May 2009 22:49:17 +0000 Received: from exch.hq.tensilica.com (exch.hq.tensilica.com [192.168.15.138]) by maia.hq.tensilica.com (8.13.1/8.13.1) with ESMTP id n44MnD7L000580; Mon, 4 May 2009 15:49:13 -0700 Received: from [172.16.150.11] (172.16.150.11) by exch.hq.tensilica.com (192.168.15.138) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 4 May 2009 15:49:12 -0700 Message-ID: <49FF70E7.7090905@tensilica.com> Date: Mon, 04 May 2009 22:49:00 -0000 From: Ross Morley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 MIME-Version: 1.0 To: Pedro Alves CC: Subject: Re: [PATCH] Program Breakpoints References: <49F9E84D.3000109@tensilica.com> <200904301930.13526.pedro@codesourcery.com> <49F9F86E.9040308@tensilica.com> In-Reply-To: <49F9F86E.9040308@tensilica.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00070.txt.bz2 Pedro, Did that make sense to you? Are you waiting for me to redo the patch with -Nurp before you look at the code? I had assumed you could look at the code and I'll redo the patch once I incorporate any feedback. Or if someone else has time to look at it... ? Refer to http://sourceware.org/ml/gdb-patches/2009-04/msg00579.html for discussion and patch. Thanks, Ross Ross Morley wrote: > > Pedro Alves wrote: > >> Before looking at the code, I'd like to see the interaction of >> program breakpoints with decr_pc_after_break adjustment formalized. >> I did a quick skim and couldn't find it handled. >> >> >> E.g, if you were to implement support for this on x86 gdbserver, >> assuming int3 traps, it appears to me that the only option is >> for the target to always rewind the pc before reporting to GDB, and >> for GDB to never adjust it itself, even for regular breakpoint hits, >> otherwise, e.g., consecutive breakpoints will be mishandled. This >> also suggests that there has to be prior negotiation (qSupported) to >> enable the support. Has this been considered? >> >> > I have thought about this. I understand decr_pc_after_break is for archs > that have already incremented the PC after hitting a trap, so GDB needs > to decrement it back to the trap in order to replace it with the original > code to step over it. > > No special handling is needed for program breakpoints because: > > - decr_pc_after_break only applies to breakpoints inserted by GDB > and therefore known to GDB (adjust_pc_after_break in infrun.c > appears to only adjust the PC if it hit a software break known > to GDB). Program breakpoints are by definition not those, and > their special handling is not applied to those. If a target were > to adjust the PC for a program breakpoint, it would then have to > report a non-zero size in STOPPED_BY_TRAP_INSTRUCTION (see next > bullet), but that would not be the normal handling for such archs. > > - decr_pc_after_break archs report size==0 in their implementation > of STOPPED_BY_TRAP_INSTRUCTION(&size). That means the PC does not > need adjustment to step over a program breakpoint. GDB will report > it stopped for a program breakpoint (if it wasn't in the breakpoint > table) but will not do anything special on resume. Perhaps I should > make that clearer in the comment in target.h on that macro, by > explicit reference to decr_pc_after_break. > >> (A small request: please include the -p switch in your `cvs diff' >> commands, or add it to .cvsrc. I use -Nurp myself.) >> >> >> > OK. > > Thanks, > Ross > >