Greetings! Nick Clifton <[email protected]> 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 [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
