From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18350 invoked by alias); 23 Sep 2004 22:33:47 -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 18341 invoked from network); 23 Sep 2004 22:33:46 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 23 Sep 2004 22:33:46 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CAc9q-0002jl-Bw; Thu, 23 Sep 2004 18:33:46 -0400 Date: Thu, 23 Sep 2004 22:33:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa/dwarf] Support for attributes pointing to a different CU Message-ID: <20040923223345.GA10500@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sources.redhat.com References: <20040923045723.GA11871@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-09/txt/msg00387.txt.bz2 On Thu, Sep 23, 2004 at 05:17:54PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > This is the last logical piece I could break out of the intercu support. > > We're almost there. Only things left after this are dependence tracking > > and the queueing of multiple full CUs - 400 lines or so. > > > > The core change of this patch is in follow_die_ref. Instead of taking an > > offset and returning a DIE, it now takes an attribute and the CU in which > > the attribute was found, and returns a DIE and the CU in which the DIE > > was found. > > > > The bulky text change of this patch is in dwarf2_attr. It divides into two > > interfaces: anywhere that we are prepared to find a reference to another > > DIE, we need to call dwarf2_attr_with_cu instead. Then, any further > > operations on the returned reference need to be sure to use the returned CU. > > The reason for this is a little subtle - we're returning a reference. If > > the reference is, for example, DW_FORM_ref4, then it's an offset within some > > particular CU. If the attribute containing this reference was found by > > chasing DW_AT_specification, and DW_AT_specification was DW_FORM_ref_addr, > > then the return value of dwarf2_attr_with_cu is a relative offset to a > > different CU than the caller passed in. So if we are going to follow the > > reference, we need to know the compilation unit in which it resides. > > I may be missing something, but it seems to me some of this effort is > necessary because we hold some die references as CU-relative, and > others as .debug_info relative, depending on the form the attribute > happened to use. Wouldn't it be a simplification to have > read_attribute_value always store all DW_FORM_ref* attributes as > DW_ADDR offsets from the beginning of .debug_info? Then dwarf2_attr's > interface could remain unchanged, and we could drop all the spec_cu > variables carrying the CU to the next call to > dwarf2_get_ref_die_offset. Then, dwarf2_get_ref_die_offset could be > deleted altogether, and its calls replaced with uses of DW_ADDR. > > (This change wasn't possible in the past because we didn't pass a CU > to dwarf2_attr.) This is why I like second-person review :-) That's a brilliant idea. I will try it. -- Daniel Jacobowitz