I'm writing to report strange behaviour in libbfd, that causes a non-gnu ELF linker I've been using to fail. I have reported a bug against that linker, but I have a patch that prevents libbfd creating this problem. I'm using libbfd from arm-linux binutils-2.9.1.0.19a, with egcs 1.1.1. The problem occurs when I attempt to link the "hello world" program, compiled with gcc, with my non-gnu linker. The problem is caused by the function elf_map_symbols in bfd/elf.c generating an unnamed section symbol for the ".comment" section of an object file. This upsets my linker because it expects to map all symbols to image locations, and the ".comment" section of the object file is not part of the image. FYI: The ".comment" section normally contains the version string of the tool that generated the object. In an assembler source it is generated by the ".ident" directive. Enabling debugging for elf.c shows that this is the _only_ section symbol added by "elf_map_symbols". Section symbols for the other sections are generated by gcc. I don't know what these symbols are for, but I feel sure it can't be necessary to have one for the ".comment" section of the object. In the ELF spec it says: STT_SECTION - The symbol is associated with a section. Symbol table entries of this type exist primarily for relocation and normally have STB_LOCAL binding. --cut-- If I remove the code in elf_map_symbols that generates this symbol, (and only this symbol, in my simple example), my problems go away. This comment is from said function: --bfd/elf.c-- /* Add a section symbol for each BFD section. FIXME: Is this really necessary? */ --cut-- I'd guess it isn't necessary, and recommend removing it, after checking this is the case. Thanks, Michael. -- Michael Nonweiler ARM Ltd, 48/49 Bateman St, Cambridge, CB2 1LR, UK. tel: Cambridge (01223) 400500 fax: Cambridge (01223) 400408
Date: Thu, 11 Feb 1999 12:11:04 +0000 From: Michael Nonweiler <Michael.Nonweiler@arm.com> The problem is caused by the function elf_map_symbols in bfd/elf.c generating an unnamed section symbol for the ".comment" section of an object file. This upsets my linker because it expects to map all symbols to image locations, and the ".comment" section of the object file is not part of the image. That expectation seems like a bug. In fact, since some types of debugging informations have references between debugging sections, which require symbols in the debugging sections, I don't see how this can work in practice. FYI: The ".comment" section normally contains the version string of the Enabling debugging for elf.c shows that this is the _only_ section symbol added by "elf_map_symbols". Section symbols for the other sections are generated by gcc. I don't know what these symbols are for, but I feel sure it can't be necessary to have one for the ".comment" section of the object. I agree. However, a section symbol may be required for any section which can have relocations. Relocations can appear in sections which are not loaded, such as debugging sections. The behaviour of the GNU ELF linker was loosely based on the behaviour of the Solaris linker. That linker does add a section symbol for the .comment section. So since I think we agree that there is a bug in the linker you are using, and since adding a section symbol follows the lead of at least one other ELF linker, I'm not too inclined to change the GNU linker behaviour. Ian
In summary, I'm writing to agree with you. Thank you for your reply. More detailed comments follow... I wrote: > The problem is caused by the function elf_map_symbols in bfd/elf.c > generating an unnamed section symbol for the ".comment" section of an > object file. This upsets my linker because it expects to map all symbols > to image locations, and the ".comment" section of the object file is not > part of the image. When I say image locations here I really mean any valid location of the linker's output file, debugging information included. At 12:17 11/02/99 -0500, Ian Lance Taylor wrote: >That expectation seems like a bug. In fact, since some types of >debugging informations have references between debugging sections, >which require symbols in the debugging sections, I don't see how this >can work in practice. Yes. For example, this is an issue if you instruct the linker to remove debugging sections... (rest snipped) We intend to make our linker deal with this. Thanks, Michael.