[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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...


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]