From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Lance Taylor To: Thiemo Seufer Cc: binutils@sources.redhat.com Subject: Re: elf_link_hash_entry vs generic_link_hash_entry Date: Wed, 22 Aug 2001 07:02:00 -0000 Message-id: References: <20010822100620.Q30301@rembrandt.csv.ica.uni-stuttgart.de> X-SW-Source: 2001-08/msg00516.html Thiemo Seufer writes: > Nick Clifton wrote: > > Hi Guys, > > > > Ian Taylor has pointed out that my recent patch to elfxx-target.h > > has actually broken several elf based ports. (Specifically: pj, > > m88k, m68hc11, m68hc12, i960, d30v, arc, gen). The problem is that > > these ports uses the generic linker code to perform section > > relocation rather than having their own specific code. This breaks > > if the elf hash table structure (elf_link_hash_entry) is used > > instead of the generic_link_hash_entry structure, since the two > > structures are not compatable. The reason that my patch changed > > elfxx-target.h so that all elf backends would use elf_link_hash_entry > > is that several other parts of the elf linker rely upon using other > > fields which are only found in that structure. > > > > As I see there are three ways that we can fix this: > > > > 1. Require that all ELF backends define their own section > > relocation function and final link function. Make it a #error > > if they do not. Fix all the ports that currently do not do > > this. This is Ian's recommended solution. > > What about introducing something like generic_elf_final_link_relocate() > and generic_elf_final_link() instead of code duplication? Each ELF backend has different relocation handling, so a simple implementation of this would not work. It should, however, be possible to design a relocation structure which captured most of the essential elements of ELF relocation types--GOT creation, etc.--and then use more generic code to handle it. I think that this project should not be confused with what Nick is talking about. BTW, although I think that Nick's choice 1 is reasonable, I would actually recommend his choice 3: fix the broken code which assumes that it knows what type of hash table it is dealing with. That code will also break linking directly to S-records. Admittedly linking directly to S-records probably doesn't work, but as far as I know making it work has not been abandoned as a goal. If it has, I believe that considerable simplifications are possible. Ian