From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10591 invoked by alias); 23 Sep 2004 22:19:52 -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 10571 invoked from network); 23 Sep 2004 22:19:47 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 23 Sep 2004 22:19:47 -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 i8NMJkbT009698 for ; Thu, 23 Sep 2004 18:19:46 -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 i8NMJjr14423; Thu, 23 Sep 2004 18:19:46 -0400 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa/dwarf] Support for attributes pointing to a different CU References: <20040923045723.GA11871@nevyn.them.org> From: Jim Blandy Date: Thu, 23 Sep 2004 22:19:00 -0000 In-Reply-To: <20040923045723.GA11871@nevyn.them.org> 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-09/txt/msg00386.txt.bz2 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.)