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

From:

Camm Maguire

Subject:

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

Date:

Wed, 28 Apr 2010 10:14:54 -0400

User-agent:

Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Thanks for this dialogue.
Nick Clifton <address@hidden> writes:
> Hi Camm,
>
>> Where is all this stuff documneted, BTW?
>
> In the source code. :-) Sorry, but documentation for the internals of
> programs like readelf is basically non-existent.
>
I guess I was referring to the relocs that *weren't* in readelf.c.
>> Hopefully for all cpu's in one place?
>
> Yes. In fact there is just one function that needs to be extended to
> handle non-trivial relocs for any given architecture:
> target_specific_reloc_handling().
>
Again, see above.
>> 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?
>
> Universally no. But this could be made a configure time option so
> that by default they remain read-only (since for most environments
> they are) but if a particular host environment needs it, they can be
> made writeable. You could submit a patch to do this if you wish...
>
OK.
I had another look at readelf, and looped over 'readelf -R $i foo.o'
on my code looking for unsupported reloc warnings. I found none, to
my surprise, given your comments about function call relocs not being
handled. The code in question definitely has function calls, mostly
through pointers. Am I missing something, or is this closer than I
had thought?
Take care,
> Cheers
> Nick
>
>
>
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah