This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Main symbol file relocation - RFC


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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]