Re: binutils patches for basic generic i960-elf

Re: binutils patches for basic generic i960-elf

[Ian Lance Taylor]

   Date: Mon, 21 Jun 1999 13:35:44 -0700
   From: Richard Henderson <rth@cygnus.com>

   On Mon, Jun 21, 1999 at 01:24:04PM -0400, Ian Lance Taylor wrote:
   > I wonder if it is really correct to discard link once sections when
   > doing a relocateable link.

   I don't think so.  We got a PR about that on Friday.

I changed the linker so that it only discards link once sections if it
is building constructors.

Everyone, please let me know if you notice any problems, such as
unexpectedly large C++ executables.

Ian

Re: binutils patches for basic generic i960-elf

[Ian Lance Taylor]

   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

Re: binutils patches for basic generic i960-elf

[Richard Henderson]

On Mon, Jun 21, 1999 at 01:24:04PM -0400, Ian Lance Taylor wrote:
> I wonder if it is really correct to discard link once sections when
> doing a relocateable link.

I don't think so.  We got a PR about that on Friday.


r~

RE: binutils patches for basic generic i960-elf

[Martin Dorey]

I came across a problem when trying to improve my i960-*-elf
configuration of the egcs compiler.

My bfd config uses the generic linker - it doesn't provide an
i960-elf-specific backend relocate_section().  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 looked at what the local x86/linux linker does.  It outputs the local
symbol which has been frobbed to point to the *ABS* section.  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().

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.

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.

--

Re: binutils patches for basic generic i960-elf

[Ian Lance Taylor]

   From: Martin Dorey <Martin.Dorey@Madge.com>
   Date: Tue, 17 Aug 1999 10:27:13 +0100

   >    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.

   Que?  bfdint.texi recommends this on the grounds of efficiency and the
   ability to handle dynamic linking, neither of which I'm particularly
   bothered about for this target.  Is there anything else I'm missing out on
   by not defining the processor-specific stuff?

Actually, there's not as much as I thought.  There are various
features which you only get by defining relocate_section, but most of
them are related to dynamic linking.  The only one I see offhand which
you aren't getting is warning sections, and perhaps some error
checking involving symbol types.

   > I wonder if it is really correct to discard link once sections when
   > doing a relocateable link.

   Say all the .linkonce.t.baz sections are combined into .text.  How is the
   final link then going to know which bits to discard?  Or how would you
   handle the multiple .linkonce.t.baz sections in the relocatable output?

Certainly it would be incorrect to combine all .linkonce.t sections
into .text when doing a relocateable link.  The .linkonce.t sections
would have to preserved as independent sections in the output.

I tried not discarding the duplicate sections when doing a
relocateable link, but it failed because the linker combined the
linkonce sections into a single section, and because it caused trouble
with the MIPS ELF .reginfo section.

Ian

RE: binutils patches for basic generic i960-elf

[Martin Dorey]

>    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.

Que?  bfdint.texi recommends this on the grounds of efficiency and the
ability to handle dynamic linking, neither of which I'm particularly
bothered about for this target.  Is there anything else I'm missing out on
by not defining the processor-specific stuff?

> I wonder if it is really correct to discard link once sections when
> doing a relocateable link.

Say all the .linkonce.t.baz sections are combined into .text.  How is the
final link then going to know which bits to discard?  Or how would you
handle the multiple .linkonce.t.baz sections in the relocatable output?

> 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.

Doh!  Why didn't I ask earlier?

--