public inbox for
 help / color / mirror / Atom feed
From: Ian Lance Taylor <>
Subject: Re: ELF STT_SECTION symbol for .comment section
Date: Thu, 11 Feb 1999 09:17:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

   Date: Thu, 11 Feb 1999 12:11:04 +0000
   From: Michael Nonweiler <>

   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


  reply	other threads:[~1999-02-11  9:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-02-11  4:12 Michael Nonweiler
1999-02-11  9:17 ` Ian Lance Taylor [this message]
1999-02-12  9:51   ` Michael Nonweiler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).