From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12258 invoked by alias); 30 Apr 2009 19:14:00 -0000 Received: (qmail 12248 invoked by uid 22791); 30 Apr 2009 19:13:58 -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; Thu, 30 Apr 2009 19:13:53 +0000 Received: from [172.16.150.11] (nose.hq.tensilica.com [172.16.150.11]) (authenticated bits=0) by maia.hq.tensilica.com (8.13.1/8.13.1) with ESMTP id n3UJDonc016302; Thu, 30 Apr 2009 12:13:51 -0700 Message-ID: <49F9F86E.9040308@tensilica.com> Date: Thu, 30 Apr 2009 19:14: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: gdb-patches@sourceware.org Subject: Re: [PATCH] Program Breakpoints References: <49F9E84D.3000109@tensilica.com> <200904301930.13526.pedro@codesourcery.com> In-Reply-To: <200904301930.13526.pedro@codesourcery.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-04/txt/msg00821.txt.bz2 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