Thanks for this dialogue. Nick Clifton <[email protected]> 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 [email protected] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gcl-devel
