From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26336 invoked by alias); 15 Apr 2002 21:26:06 -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 26329 invoked from network); 15 Apr 2002 21:26:05 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 15 Apr 2002 21:26:05 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16xDzV-000122-00; Mon, 15 Apr 2002 17:26:25 -0400 Date: Mon, 15 Apr 2002 14:26:00 -0000 From: Daniel Jacobowitz To: Elena Zannoni Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Relocate debug information in object files (e.g. add-symbol-file) Message-ID: <20020415172625.A3556@nevyn.them.org> Mail-Followup-To: Elena Zannoni , gdb-patches@sources.redhat.com References: <20020404170610.A3717@nevyn.them.org> <15547.16869.937738.748385@localhost.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15547.16869.937738.748385@localhost.redhat.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00541.txt.bz2 On Mon, Apr 15, 2002 at 05:11:01PM -0400, Elena Zannoni wrote: > Daniel Jacobowitz writes: > > This fixes a nasty problem debugging kernel modules on PowerPC. The test is > > in my previous message to this list today; it fixes: > > FAIL: gdb.base/relocate.exp: static variables have different addresses > > > > The problem goes like this: We know, when loading a new file at a specified > > offset, that addresses in debug info are going to be a bit off. We shift > > them all by the appropriate constants (well, sometimes the appropriate > > constants. PowerPC has other problems with .data vs .sdata occasionally). > > Shifting by constant section offsets is all we do. > > > > On i386 and many other targets this suffices. Why? Because the debug info > > looks like this: > > 22 STSYM 0 1 00000000 934 static_foo:S(0,1) > > 23 STSYM 0 2 00000004 952 static_bar:S(0,1) > > 0000011c 00000301 R_386_32 00000000 .data > > 00000128 00000301 R_386_32 00000000 .data > > > > On PowerPC, it doesn't look like that at all. I believe the reason has to > > do with the ABI allowing .sdata optimizations. It may also show up on other > > architectures that use RELA; even though the offset will still be against > > the section in that case, it will be shifted into the relocation entry > > instead of the debug info directly. Instead we have: > > 22 STSYM 0 1 00000000 948 static_foo:S(0,1) > > 23 STSYM 0 2 00000000 966 static_bar:S(0,1) > > 0000011c 00601 R_PPC_ADDR32 00000000 static_foo + 0 > > 00000128 00701 R_PPC_ADDR32 00000004 static_bar + 0 > > > > The important changes are: the +4 in static_bar's stab has disappeared, and > > the relocations are now against symbols. > > > > The only way to make sense of this is to relocate the section. It turned > > out to be easier than I feared. BFD provides (almost) the perfect hooks; we > > need to fake a couple of data structures in order to pretend that we're a > > linker, but that's it. One consequence is that (in the case of an object > > file only, not in the unchanged normal case) we preread the entire stabs > > debug section. Since this will only happen for individual object files, and > > we don't keep it around, the memory increase doesn't worry me. The > > relocation itself is blindingly fast (imperceptible on a module I have here > > with 4000 relocations and tons of symbols). > > > > How does this patch look? OK to commit? > > > > Sorry, I don't like it too much. > > You are using PTR, I would prefer if you didn't. True/false were both > eliminated from gdb. Also, I don't really like the idea to introduce Both easily fixed. Sorry about missing the true/false thing; I introduced not a single new use of PTR (just moved) but if you'd rather I can eliminate them. They were already present. > the dummy functions. Would it be possible to add something to bfd to > provide a better interface that is not just taylored to the linker? > For instance bfd has the file linker.c to provide such an > interface. Could we have a debugger.c file? How about writing a > simplified version of bfd_generic_get_relocated_section_contents so the > need of the dummy parameters would be eliminated? In a sense you already > have started that in symfile_relocate_debug_section. Well, I can not redo it so that the dummy arguments are not necessary. This is a hook into a substantial portion of BFD, and e.g. the error functions are assumed present. I could theoretically provide them internally in BFD and come up with a new entry point... but I can't wrap my head around what it should look like. I'll think about this. > I also am not sure about the use of the global stabs_data. I know > dbxread.c is not the best written file in gdb, but... Maybe you can > have accessor functions? Don't know, stabs_seek ? Stabs_seek would > decide whether to do a bfd_seek or a buffer pointer/counter adjustment. I actually was going to redo this with stabs_seek this week. Peter Schauer pointed out that I can get better performance by relocating in dbx_psymtab_to_symtab instead of read_ofile_symtab. Thanks for the comments. I won't have time to address them for a little while, but I'll redo the patch with corrections when I do. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer