public inbox for bfd@sourceware.org
 help / color / mirror / Atom feed
From: Michael Nonweiler <Michael.Nonweiler@arm.com>
To: bfd@cygnus.com
Cc: Sumit.Sahai@arm.com
Subject: ELF STT_SECTION symbol for .comment section
Date: Thu, 11 Feb 1999 04:12:00 -0000	[thread overview]
Message-ID: <199902111212.MAA02147@bsun1.arm.com> (raw)

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


             reply	other threads:[~1999-02-11  4:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-02-11  4:12 Michael Nonweiler [this message]
1999-02-11  9:17 ` Ian Lance Taylor
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=199902111212.MAA02147@bsun1.arm.com \
    --to=michael.nonweiler@arm.com \
    --cc=Sumit.Sahai@arm.com \
    --cc=bfd@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).