This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: -gc-sections for elf32-dlx and possible buglette in elf32-target.h
- From: "Dave Korn" <dk at artimi dot com>
- To: "'Daniel Jacobowitz'" <drow at mvista dot com>
- Cc: <binutils at sources dot redhat dot com>
- Date: Thu, 29 Jan 2004 16:24:25 -0000
- Subject: 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 ?
Thanks,
DaveK