Re: elf_link_hash_entry vs generic_link_hash_entry

[Ian Lance Taylor <ian at zembu dot com>]

Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> 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