From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Lance Taylor To: martin.dorey@madge.com Cc: binutils@sourceware.cygnus.com Subject: Re: binutils patches for basic generic i960-elf Date: Thu, 01 Jul 1999 00:00:00 -0000 Message-id: <19990621172404.27917.qmail@daffy.airs.com> References: <376DFC6D.6BB3A44@madge.com> <376DFC6D.6BB3A44@madge.com> X-SW-Source: 1999-q2/msg00310.html Date: Mon, 21 Jun 1999 09:48:45 +0100 From: 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. 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