[Gcl-devel] Re: bfd_get_relocated_section_contents on hppa and ia64

[Camm Maguire]

Greetings!

Nick Clifton <address@hidden> writes:

> Hi Camm,
>
>> Greetings!  Am looking into your suggestion re: readelf relocation
>> code.  I've found this comment:
>>
>> /* Apply relocations to a section.
>>     Note: So far support has been added only for those relocations
>>     which can be found in debug sections.
>>     FIXME: Add support for more relocations ?  */
>>
>> Not sure what this means.
>
> What it means is that the code in readelf only implements a subset of
> the possible relocations that any given target can produce.  In
> particular it only implements those relocations which can be found
> inside DWARF debug sections.  So for example it implements relocations
> to insert 32-bit values, but not relocations to fix up function calls.
>
>> I need the relocated code to be executable.
>> Does the above indicate that this implementation won't suffice for
>> this purpose?
>
> Yes.  Or rather "yes unless you put further work into it".  Adding
> support for other relocations is not that hard.  Providing that you
> have the documentation describing what they do, that is.
>
> If you have a look at the function apply_relocations() in readelf.c
> you will see a for() loop that walks over the relocations for a given
> section applying them one by one.  If it comes across a relocation
> that it does not know how to implement it issues a warning message.
> But just before that warning there is a call to
> target_specific_reloc_handling(). This is where you would add the code
> to handle any HPPA and IA64 relocations that are not currently
> supported by readelf.
>

Where is all this stuff documneted, BTW?  Hopefully for all cpu's in
one place?

> The main reason I suggested looking at the readelf code is that it has
> most of the framework for handling relocations in place, just not the
> specific code to handle every possible relocation on every possible
> target.  The BFD library also has code to handle relocations, and it
> does cover every possible relocations - but it is a lot harder to
> understand.
>

Indeed it is.  And another disadvantage from GCL's perspective is that
bfd mallocs considerable memory.  We redirect malloc into a linked
list managed by GCL's garbage collector, but this is slow and can
fragment.  We dump images with unexec, like emacs, so the bfd for the
running image is in memory perpetually.  Separate bfd's are opened
temporarily for each object file to be loaded.

GCL has its own simplified elf loader for i386 and sparc.  I put in
the bfd support in an attempt to outsource this functionality to the
experts, who have to maintain it anyway in supporting new targets as
they come along.  I was trying to avoid learning the reloc formats for
12+ platforms.  And it did get me without any trouble m68k, arm,
sparc, s390, ppc, i386, amd64.  I managed to extend it slightly to
cover mips, mipsel, and alpha.

Given what you write above, bfd still seems the way to go, in
principle at least.  For mips(el) and alpha, I need to rewrite the
howto functions.  (The idea here is to append .got sections and reloc
into these as a kind of trampoline.)  This is fairly modular, but for
the fact that bfd stores these pointers in constant memory.  I have to
fork the tree in the GCL source and remove the const declaration for
this to work.  This is obviously not optimal.  Could we make the howto
pointers writable?

Take care,

> Cheers
>   Nick
>
>
>
>
>

-- 
Camm Maguire                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah