public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Boehm, Hans" <hans_boehm@hp.com>
To: "'binutils@sources.redhat.com'" <binutils@sources.redhat.com>
Cc: "'Manuel Serrano'" <Manuel.Serrano@sophia.inria.fr>,
	Hans Boehm <boehm@acm.org>,
	"'Kenneth C. Schalk'" <ken@xorian.net>,
	"'tromey@redhat.com'" <tromey@redhat.com>
Subject: Weak versioned symbols?
Date: Mon, 28 Apr 2003 23:47:00 -0000	[thread overview]
Message-ID: <75A9FEBA25015040A761C1F74975667D01442060@hplex4.hpl.hp.com> (raw)

Ken Schalk and Manuel Serrano pointed out a bug that shows up in my garbage collector.  It is also reported in http://bugs.debian.org/165837 .

My garbage collector currently refers to __libc_stack_end as a weak symbol.  This symbol is no longer exported in glibc 2.3.  I'm referring to it because there isn't yet an adequate replacement in deployed glibc versions, and my fallback algorithm for Linux is slower and relies on /proc, which may not always be available.

The problem is that this appears to generate a runtime error if an executable was linked against glibc 2.2, but is then run in a 2.3 environment.  My understanding was that weak symbols were introduced precisely to avoid this problem?  What went wrong? Is this related to the patch in http://sources.redhat.com/ml/binutils/2003-04/msg00239.html ? 

Thanks for any insight.

Hans

Here's part of Ken's description of what happens:

[Ken:]
...I ran into a thorny issue with __libc_stack_end and different
versions of the GNU libc.  The problem I had was exhibited by this
message:

relocation error: symbol __libc_stack_end, version GLIBC_2.1 not defined
in file ld-linux.so.2 with link time reference
Because of the way Vesta works, my builds of the collector (and
everything linking with it) get done in a change-root environment that
can be somewhat different from what's installed on the system I
subsequently run the binaries on.  In the case where I saw this, I was
compiling in an environment with a 2.2 GNU libc and running in an
environment with a 2.3 libc.
...

I'm not sure who to pin the blame on, but the symbol does seem to get
resolved at link time (to either "__libc_stack_end@@GLIBC_PRIVATE" or
"__libc_stack_end@@GLIBC_2.1").  At run-time (when the error occurs),
it's definitely no longer a weak symbol.

                 reply	other threads:[~2003-04-28 23:47 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=75A9FEBA25015040A761C1F74975667D01442060@hplex4.hpl.hp.com \
    --to=hans_boehm@hp.com \
    --cc=Manuel.Serrano@sophia.inria.fr \
    --cc=binutils@sources.redhat.com \
    --cc=boehm@acm.org \
    --cc=ken@xorian.net \
    --cc=tromey@redhat.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).