public inbox for bfd@sourceware.org
 help / color / mirror / Atom feed
* ELF STT_SECTION symbol for .comment section
@ 1999-02-11  4:12 Michael Nonweiler
  1999-02-11  9:17 ` Ian Lance Taylor
  0 siblings, 1 reply; 3+ messages in thread
From: Michael Nonweiler @ 1999-02-11  4:12 UTC (permalink / raw)
  To: bfd; +Cc: Sumit.Sahai

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: ELF STT_SECTION symbol for .comment section
  1999-02-11  4:12 ELF STT_SECTION symbol for .comment section Michael Nonweiler
@ 1999-02-11  9:17 ` Ian Lance Taylor
  1999-02-12  9:51   ` Michael Nonweiler
  0 siblings, 1 reply; 3+ messages in thread
From: Ian Lance Taylor @ 1999-02-11  9:17 UTC (permalink / raw)
  To: Michael.Nonweiler; +Cc: bfd, Sumit.Sahai

   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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: ELF STT_SECTION symbol for .comment section
  1999-02-11  9:17 ` Ian Lance Taylor
@ 1999-02-12  9:51   ` Michael Nonweiler
  0 siblings, 0 replies; 3+ messages in thread
From: Michael Nonweiler @ 1999-02-12  9:51 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: bfd, Sumit.Sahai

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.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1999-02-12  9:51 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-02-11  4:12 ELF STT_SECTION symbol for .comment section Michael Nonweiler
1999-02-11  9:17 ` Ian Lance Taylor
1999-02-12  9:51   ` Michael Nonweiler

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).