This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Main symbol file relocation - RFC
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: Main symbol file relocation - RFC
- From: Duncan Coutts <dcoutts at cray dot com>
- Date: Fri, 10 Aug 2001 12:11:46 -0500
- cc: <gdb at sources dot redhat dot com>
Hi,
This is an RFC on a generalisation of syms_from_objfile (gdb/symfile.c)
On Fri, 10 Aug 2001, Andrew Cagney wrote:
> > Yes, I know it's odd, but the MPI library that I am using dynamically
> > relocates the a.out by a given offset. I am trying to extend gdb for this
> > target to relocate its symbol table information so that it matches up
> > properly.
>
> I take it that a.out just happens to be the object format and the theory
> should generalize.
Sorry, I meant a.out as in the name of the executible file, I'm actually
using elf format.
[...]
> > However a snag that I have hit is this, the 'mainline' parameter of
> > the function 'syms_from_objfile'. It is supposed to be set for the main
> > symbol file (ie the a.out). It does some special cleanup stuff, however it
> > also assumes (quite reasonably) that the main symbol file will not have
> > any relocation offset for any of its sections and so sets them to zero
> > thus defeating my efforts to do the relocation.
> >
> > So I was wondering what the "Right Way(tm)" to do this is? I can hack it
> > and add some feature specific #define. I would rather change the semantics
> > of the function to seperate the house cleaning tasks from the assumptions
> > about relocation. The callers of the function would then need to make sure
> > they set the correct loading addresses rather than relying on the default.
> > If that change would be too painful, perhaps the best solution would be
> > some extra global #define which defaults to the current behaviour, but
> > which specific targets can override to allow relocation of the mainline.
>
> At a general level. I'd suggest working on the assumption that adding
> #idef's and #define's would not be popular - gdb is moving towards
> having everything tweekable at run time.
>
> You may even be able to sell this as a simplifying generalization. As
> you note, why should main be treated different?
Well, in that case, here's a first draft of a patch along those lines. The
idea is that the mainline parameter just specifies that certian
housekeeping operations be performed while the addrs parameter
*independantly* specifies the load addresses. A NULL value for addrs still
means use the default load address. This is compatible with the current
usage where (mainline => (addrs==NULL)) that is mainline being true
implies that the addrs parameter is NULL. I have checked all the places
where syms_from_objfile (or rather its wrappers) is called and they all
use it that way. (I checked this on the 5.0 release, but I could check
again before any final commit)
Duncan
Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.36
diff -r1.36 symfile.c
545,546c545,547
< ADDR is the address where the text segment was loaded, unless the
< objfile is the main symbol file, in which case it is zero.
---
> ADDR is the address where the text segment was loaded. A null pointer
> indicates to use no offsets, ie the values from the bdf.
> It is now possible to specify a load address for the main symbol file.
563a565
> int no_load_address_specified=0;
567a570
> /* Actually, we explicitly record that no load address was specified */
572a576
> no_load_address_specified = 1;
610c614
< if (!mainline)
---
> if (no_load_address_specified)