Main symbol file relocation

[Duncan Coutts <dcoutts at cray dot 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.

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.

I also note that in places 'mainline' is mentioned as a hack, so I was
wondering how sacred it was. I know that this is an obscure case, but it
seems like the mechanisms are already there, so I could  do this with
little or no change to generic code.

Cheers for any info or suggestions.

Duncan