From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26913 invoked by alias); 25 Jul 2003 23:08:19 -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 26890 invoked from network); 25 Jul 2003 23:08:18 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 25 Jul 2003 23:08:18 -0000 Received: from drow by nevyn.them.org with local (Exim 4.20 #1 (Debian)) id 19gBfc-0007yl-ID; Fri, 25 Jul 2003 19:08:16 -0400 Date: Fri, 25 Jul 2003 23:08:00 -0000 From: Daniel Jacobowitz To: daniel.van.gerpen@philips.com Cc: gdb@sources.redhat.com Subject: Re: dwarfread / multiple compilation units Message-ID: <20030725230816.GA21679@nevyn.them.org> Mail-Followup-To: daniel.van.gerpen@philips.com, gdb@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-07/txt/msg00309.txt.bz2 On Fri, Jul 25, 2003 at 09:35:22PM +0100, daniel.van.gerpen@philips.com wrote: > Hi, > > I stumbled onto several problems using the Gnu Debugger 5.3 with code > from the Diab Compiler 4.4b. > > One problem is the following: > > The compiler option -Xsplit-section creates a separate section for each > function to allow the linker to remove it during linking when it is not > used. The option also splits the debug information for types into > different compilation units: > In dwarfread.c the function lookup_utype() now complains about a bad die > reference, because read_ofile_symtab() only reads the dies from one > compilation unit (unit B). The result is that gdb only shows the variable > "foo" to be of type "int" instead of type "Cfoo". > > Maybe someone already has a patch for this? > > If not, what would be an appropriate solution? I have been pondering about > a > possible fix. To read all dies from all compilation units could be a > problem > for code with a huge amount of debug information. > > A better way would be to reload the missing information when it is needed. > But I am not sure how to load dies from other compilation units for > example > in lookup_utype(). This will be extremely hard to fix. The DWARF-2 reader has the same problem, and I or someone else will see that it gets fixed. But it is unlikely that any of the maintainers will put in that much effort for the DWARF 1 reader. Really, kick your compiler vendor. DWARF 2 is a good number of years old now. They should switch. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer