From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6427 invoked by alias); 16 Oct 2003 23:14:25 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6420 invoked from network); 16 Oct 2003 23:14:24 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 16 Oct 2003 23:14:24 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h9GNEOM09666 for ; Thu, 16 Oct 2003 19:14:24 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h9GNEDL12182; Thu, 16 Oct 2003 19:14:13 -0400 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h9GNECJ01896; Thu, 16 Oct 2003 16:14:12 -0700 Message-ID: <3F8F2644.4080207@redhat.com> Date: Thu, 16 Oct 2003 23:14:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com Subject: Re: RFA: Breakpoint infrastructure cleanups [0/8] References: <3F846B04.2070801@redhat.com> <3F85B4AC.7000000@redhat.com> <20031014013831.GB6118@nevyn.them.org> <3F8C18DD.3020508@redhat.com> <20031014155126.GA10669@nevyn.them.org> <3F8C605E.1060604@redhat.com> <3F8D6181.6070409@redhat.com> <3F8D8FEB.8020305@redhat.com> <16269.39677.813094.890124@localhost.redhat.com> <2719-Thu16Oct2003085405+0200-eliz@elta.co.il> <20031016131144.GA14202@nevyn.them.org> In-Reply-To: <20031016131144.GA14202@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00573.txt.bz2 Daniel Jacobowitz wrote: > On Thu, Oct 16, 2003 at 08:54:05AM +0200, Eli Zaretskii wrote: > >>>From: Elena Zannoni >>>2. hit the breakpoint, show line info about where we stopped, and >>> breakpoint number. Do we just say the program hit the high level >>> breakpoint number, or also which low level breakpoint number? >> >>I'd say we show the high-level number and the precise machine address >>where it breaks. > > Right now we show the breakpoint address for breakpoints which are not > at the beginning of a source line, and just the breakpoint and line > numbers for breakpoints which are at the beginning of a line. How > would this interact with that? Show the address always, or for > breakpoints which either are in the middle of a line or in multiple > locations? I think right now we show the address only when it doesn't have a clear one-to-one relationship with a source location. For instance if it falls in the middle of a line, or a function prologue (same thing, actually, it's just a special case of a line). In the one-to-many case, I'd say that if the breakpoint has a fan-out of one (ie. only one location), AND it corresponds to a specific source line, then we just report the line. For mid-lines, we do the same as before (show the address). If it's a breakpoint with multiple locations, then we need to qualify it -- distinguish somehow which one was hit. The way to qualify it might depend on the kind of fan-out. In many cases, the source file might be enough. Or maybe the function signiture. I'm still in the fog about the machine-generated constructors... >>> Hmm, do low level breakpoints have numbers? >> >>I don't think we need numbers for them, so let's not have them. > > I actually think that we do need numbers for them. I suspect so too. > > My hypothetical use case is something like this: > (gdb) break inline_foo > Breakpoint 5 set at inline_foo, which has multiple locations. > Say "info breakpoint 5" for more details. > (gdb) info break 5 > Num Type Enb Address What > 1 sw breakpoint y 0x8040222 inlined into foo > 2 sw breakpoint y 0x8040822 inlined into bar > 3 sw breakpoint y 0x8040852 inlined into boring_loop > (gdb) disable 5.3 > (gdb) run > > I am not sure about "delete 5.3", though - that makes tracking which > breakpoints have been set a little trickier, for not much gain.