ELF STT_SECTION symbol for .comment section

Michael Nonweiler Michael.Nonweiler@arm.com
Thu Feb 11 04:12:00 GMT 1999

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-, 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:
The symbol is associated with a section. Symbol table entries of this type
exist primarily for relocation and normally have STB_LOCAL binding.

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:
/* Add a section symbol for each BFD section.  FIXME: Is this really
   necessary?  */

I'd guess it isn't necessary, and recommend removing it, after checking
this is the case.



Michael Nonweiler
ARM Ltd, 48/49 Bateman St, Cambridge, CB2 1LR, UK.
tel: Cambridge (01223) 400500  fax: Cambridge (01223) 400408

More information about the Bfd mailing list