Main symbol file relocation

[Andrew Cagney]

> 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