From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25571 invoked by alias); 20 Oct 2004 16:02:34 -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 25538 invoked from network); 20 Oct 2004 16:02:30 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 20 Oct 2004 16:02:30 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i9KG2UQa007749 for ; Wed, 20 Oct 2004 12:02:30 -0400 Received: from zenia.home.redhat.com (sebastian-int.corp.redhat.com [172.16.52.221]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i9KG2Or26239; Wed, 20 Oct 2004 12:02:24 -0400 To: David Lecomber Cc: Daniel Jacobowitz , patches Subject: Re: RFC: The Constructor Breakpoint Issue References: <1097714229.11117.99.camel@localhost.localdomain> <1097847699.1773.81.camel@localhost.localdomain> <20041015145144.GB25188@nevyn.them.org> <1098277715.628.20.camel@delmo.priv.wark.uk.streamline-computing.com> From: Jim Blandy Date: Wed, 20 Oct 2004 16:02:00 -0000 In-Reply-To: <1098277715.628.20.camel@delmo.priv.wark.uk.streamline-computing.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-10/txt/msg00340.txt.bz2 David Lecomber writes: > > You can't tell from the line table. You can tell if you have both a > > line table and a .debug_info section; in the case that is interesting > > to you, the two PCs will be in different DW_TAG_subprogram trees. > > Given the order in which we parse things I'm not sure if you'll be able > > to check that easily. > > How about this idea.. Getting into the dwarf2 area looks like quite a > major set of mods, which ultimately will be supported only by the > dwarves, which is not good. However, inspection of the result of > find_pc_function() suggests it is different on the occasions when it > needs to be, such as in C++ constructors, and the same when we want it > to be - such as the start and end of for loops. What you're suggesting here, if I understand, is to take all the occurrences of a given source line in the line table (and there may be many, due not just to things like 'for' loops, but also due to instruction scheduling and other sorts of optimizations), look to see which function each falls in, and report the first occurrence from each function. Sounds good to me (although note that I don't approve symtab changes any more, so this is just advice). Some thoughts: The line number lookup code actually looks for "best" matches, not just exact matches; see symtab.c:find_line_common. Preserving that behavior will require a bit of care. The downside that comes to mind is that this approach requires GDB to always traverse the full linetable, instead of stopping as soon as it finds an exact match, as it does now. It'll be a substantial change to the line lookup machinery, since those functions are not designed, at present, to return multiple values. But it's not that hairy in the aerial view. There are some opportunities for optimization. A symtab's linetable and its blockvector's blocks are both sorted in order of increasing addresses. So one could traverse the blockvector and linetable in parallel (skipping blocks that don't represent functions), and avoid doing a full symbol lookup by pc for each plausible line.