This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: -gc-sections for elf32-dlx and possible buglette in elf32-target.h

> -----Original Message-----
> From: Daniel Jacobowitz 
> Sent: 29 January 2004 16:00

  Daniel, thanks for taking the time to cast an eye over this for me; it's
most kind of you.

> On Thu, Jan 29, 2004 at 03:51:28PM -0000, Dave Korn wrote:
> > can possibly be valid.  The code a few lines above it 
> initialises the 
> > h pointer like this:
> > 
> > 	  if (sym->udata.p != NULL)
> > 	    h = (struct generic_link_hash_entry *) sym->udata.p;
> Didn't realize it was a generic_link_hash_entry, sorry.  In 
> that case you can not use the generic linker unless you 
> derive from generic_link_hash_entry.  Which conflicts with 
> using elf_link_hash_entry...

  Indeed! :-/

> I assume 
> > that the udata.p members of all the symbol structures are 
> supposed to 
> > point to a hash entry of whatever derived type we're using, rather 
> > than some auxiliary generic linker hash table that also 
> exists.  And 
> > I'm led to assume that this happens because I've #defined 
> some of the 
> > backend overrideables, but not a consistent set of them.
> ... which means that if you want to use ELF-specific 
> features, like the one you are trying to use, you can not use 
> the generic linker.

  Right.  Looks like my initial diagnosis was more-or-less right, so the
problem then boils down to this:

1)  I want to use ELF-specific features; therefore I don't want to use the
generic linker but the elf linker.  Currently the elf32-dlx backend is a
somewhat minimal implementation that doesn't actually use ELF hash tables or
the ELF linker: it uses the generic equivalents.

2)  Unfortunately, there's that bit of code I quoted from elf32-target.h
that forces the generic link routines on me if I don't define
elf_backend_relocate_section.  It also causes an inconsistent set of
routines to be used; it's basically wrong in the case where there isn't a
backend relocate section routine defined but there is a derived hash table
in use.  I don't know if that would ever be a valid case.

3)  There's no documentation anywhere that I can find on what
inter-dependencies there are among the backend overrideables.  I guess I'm
going to have to write a backend_relocate_section routine in order to get
the ELF linker used.  Does that also mean I have to supply routines for
bfd_elf32_bfd_link_add_symbols and bfd_elf32_bfd_final_link ?  Are there any
generic-elf versions of these routines that I can call into play, or are
they vastly different for different target architectures ?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]