From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28092 invoked by alias); 31 Jul 2003 05:16:55 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 28081 invoked from network); 31 Jul 2003 05:16:54 -0000 Received: from unknown (HELO sccrmhc13.comcast.net) (204.127.202.64) by sources.redhat.com with SMTP; 31 Jul 2003 05:16:54 -0000 Received: from lucon.org ([12.234.88.5]) by comcast.net (sccrmhc13) with ESMTP id <2003073105165401600b2tsfe>; Thu, 31 Jul 2003 05:16:54 +0000 Received: by lucon.org (Postfix, from userid 1000) id B75112C4EC; Thu, 31 Jul 2003 05:16:53 +0000 (UTC) Date: Thu, 31 Jul 2003 05:16:00 -0000 From: "H. J. Lu" To: GDB Subject: Re: DW_FORM_ref_addr dosn't work Message-ID: <20030731051653.GB1170@lucon.org> References: <20030730214252.GA26082@lucon.org> <20030730214503.GA15350@nevyn.them.org> <20030730215227.GA26318@lucon.org> <20030730215509.GA15640@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030730215509.GA15640@nevyn.them.org> User-Agent: Mutt/1.4.1i X-SW-Source: 2003-07/txt/msg00362.txt.bz2 On Wed, Jul 30, 2003 at 05:55:09PM -0400, Daniel Jacobowitz wrote: > On Wed, Jul 30, 2003 at 02:52:27PM -0700, H. J. Lu wrote: > > On Wed, Jul 30, 2003 at 05:45:03PM -0400, Daniel Jacobowitz wrote: > > > On Wed, Jul 30, 2003 at 02:42:52PM -0700, H. J. Lu wrote: > > > > DW_FORM_ref_addr can reference an entry in a different compilation > > > > unit, even from a different shared object. But die_ref_table only > > > > contains DIEs in one single compilation unit. Why do we do that? What > > > > is the best way to fix it? > > > > > > > > BTW, I am enclosing my quick dirty hack for reference. > > > > > > Please read any of the thirty-some discussions of this in the list > > > archives. > > > > > > I'm working on it in my spare time, of which I have not had enough to > > > make much progress. The DWARF reader needs to be essentially > > > rewritten. > > > > While waiting for your new DWARF reader, I will see how my hack > > goes :-(. > > Since the die table is hashed by offset (isn't it?), presumably very > badly. It is OK for different compilation units within the same .debug_info section. H.J.