This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: binutils patches for basic generic i960-elf
- To: martin.dorey@madge.com
- Subject: Re: binutils patches for basic generic i960-elf
- From: Ian Lance Taylor <ian@zembu.com>
- Date: 21 Jun 1999 13:24:04 -0400
- CC: binutils@sourceware.cygnus.com
- References: <376DFC6D.6BB3A44@madge.com>
Date: Mon, 21 Jun 1999 09:48:45 +0100
From: Martin Dorey <martin.dorey@madge.com>
My bfd config uses the generic linker - it doesn't provide an
i960-elf-specific backend relocate_section().
In general, I recommend writing this. Without it, you won't get many
of the features of the ELF linker.
When I try to do a
relocatable link of two files containing simply:
.section .gnu.linkonce.t.GetLength__C6Marble
.stabd 68,0,4
I get a link error "link: symbol `L0`' required but not present". The
problem comes because the .stabd causes a local symbol to be generated
in order for a stab relocation to refer to. The second duplicate of the
linkonce section gets correctly discarded, along with this local
symbol. When the linker comes to output the relocations for the .stab
section, it fails because it has to output a relocation that refers to a
symbol that isn't being output.
I wonder if it is really correct to discard link once sections when
doing a relocateable link.
I looked at what the local x86/linux linker does. It outputs the local
symbol which has been frobbed to point to the *ABS* section.
Pointing to the absolute section in this way is probably a bug, not a
feature.
The code
that causes this is in elf_link_input_bfd() (search for "needed by a
reloc"). I'm wondering whether or not it would be a good idea for the
generic linker to support the same behaviour - when scanning the relocs,
output any symbols that haven't been already output. This seemed a bit
complicated to do - involving perhaps passing the
generic_write_global_symbol_info to bfd_canonicalize_relocs() to
elf_slurp_reloc_table().
I'm not sure why elf_slurp_reloc_table comes into this. It should be
possible to do it all within _bfd_generic_final_link. That function
builds the symbol table before building the relocs, but I think it
should be possible to add symbols while reading the relocs. I haven't
thought about it too hard, though.
It would be quite possible for the linker to go one better than
elf_link_input_bfd() does at the moment, and make the output symbol
refer to the correct place in the correct section. One idea I had for
doing this was to add a field to asection - asection* duplicate_of; -
which the linker (ldlang.c:section_already_linked()) would fill in when
it decides to discard a duplicate linkonce section. Later on, when
scanning the relocs and coming across a symbol in a section that has a
duplicate_of and an output_section of bfd_abs_section, the linker could
output a symbol with the value of the original symbol plus the offset of
the duplicate_of section in the output section and fix the reloc to
refer to this.
I hate to add a new field to asection. However, this general approach
does make sense to me.
More realistically, if the current behaviour is not right, then it might
be worthwhile documenting it for the benefit of anyone creating a new
elf architecture.
I would be happy to accept patches to bfd/doc/bfdint.texi.
Incidentally, I recently fixed a long standing bug in gas to stop it
from outputting relocs against local symbols in linkonce sections.
This may work around your problem in a different way.
Ian