This is the mail archive of the binutils@sourceware.cygnus.com 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]

Re: binutils patches for basic generic i960-elf


   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

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