This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Main symbol file relocation
- To: Duncan Coutts <dcoutts at cray dot com>
- Subject: Re: Main symbol file relocation
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Fri, 10 Aug 2001 01:25:59 -0400
- Cc: gdb at sources dot redhat dot com
- References: <Pine.SGI.4.33.0107261643220.35254-100000@underbird7.mw.cray.com>
> Hi all,
>
> 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.
> Now it seems like the 'shared library / dynamicly loaded code' features of
> gdb ought to be able to cope with this. (In fact it's a much more simple
> case than dynamic librarys, since the code is only loaded once and it is
> done before we attach.) So it seems like we just need to set up the
> appropriate section_addr_info structure in the same manner as solib.c
> (and others) do and things will be taken care of.
>
> 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?
Andrew