From: Zack Weinberg <zackw@panix.com>
To: libc-alpha@sourceware.org
Subject: Re: Evolution of ELF symbol management
Date: Wed, 16 Nov 2016 15:55:00 -0000 [thread overview]
Message-ID: <0c682496-5c13-b3c5-ff66-0f8923a1d6e3@panix.com> (raw)
In-Reply-To: <9727f95a-df3d-ec11-8c1d-9b7ea6cbcaac@redhat.com>
On 10/18/2016 05:26 AM, Florian Weimer wrote:
> With this message, I want to start a discussion why this symbol
> mangling stops at glibc-internal cross-DSO references (or static
> linking). Wouldn't other system libraries, such as libstdc++, glib,
> Qt and so on need to do the same thing? After all, if Qt calls
> foo@GLIBC_2.31, and the main program defines foo (which the static
> linker automatically exports to enable interposition), we almost
> certainly would want Qt to continue to call foo@GLIBC_2.31, and not
> the potentially incompatible implementation of foo in the main
> program.
>
> To keep things simple, I suggest that for all new function symbols,
> we declare __libc_foo in the header file, redirect foo to
> __libc_foo, export both at the same symbol version from the DSO, and
> make __libc_foo a strong definition and foo a weak one. (We should
> not add new variable symbols.)
>
> For existing symbols, we only do this if we receive reports of
> conflicts causing problems in the field. In this case, we add
> __libc_foo and the redirect to the header file, and use the current
> symbol version for the __libc_foo export (not the one of foo).
I meant to respond to this last month but have not been able to scrape
time away from $DAYJOB until this week. Apologies.
First, I don't have a problem with adding __libc_* aliases as
non-default but public alternative names, so that third-party libraries
can avoid namespace pollution in static linkage and/or choose to refer
to symbols that are more likely to get resolved to the C library's
export than to a colliding symbol in the main executable. I'd reserve
that for cases where there is already a demonstrated need, though, such
as libstdc++. I also don't have a problem with a hypothetical policy
that all new symbols that aren't in the current revisions of C+POSIX
should be given an impl-namespace name as their primary definition, with
the user-namespace name being a weak alias (but still the only name used
in the public headers).
I _do_ have problems with causing these symbols to be used by default.
My main concern is that I think it's tackling the problem in the wrong
place. If we want to back away from the original principle that the
executable always wins, isn't an expanded version of -Bsymbolic mode
what's _really_ wanted? That is, an opt-in link-time declaration that
you want all dynamic symbols resolved at load-time to the same library
that provided them at link-time. Once that exists, we could try to move
slowly in the direction of turning it on by default, along with various
other "yes, fix the bug" linker toggles like -z relro and --as-needed.
Until and unless this possibility has been thoroughly explored and
determined unworkable, I will object to bulk addition of __libc_*
aliases, and to an "all new public prototypes must redirect to a
__libc_* alias" rule.
A secondary reason for not wanting __libc_* aliases to be activated by
default is that it doesn't seem to me that it actually solves the
problem. Applications that _want_ to interpose are going to shift to
the __libc_* names; depending on what the headers actually do,
applications that don't care (but do define a conflicting symbol) might
wind up shifting to those names by accident. __REDIRECT doesn't work
without GCC(-compatible) extensions, after all. (I would not object to
a _documented and enforced_ set of GCC-compatible extensions being a
baseline requirement for use of glibc headers -- but that would need to
happen _first_.)
zw
next prev parent reply other threads:[~2016-11-16 15:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-18 9:26 Florian Weimer
2016-10-18 16:50 ` Joseph Myers
2016-10-25 14:32 ` Florian Weimer
2016-10-25 15:37 ` Joseph Myers
2016-11-21 15:35 ` Florian Weimer
2016-10-26 12:17 ` Joseph Myers
2016-11-20 11:13 ` Mike Frysinger
2016-11-21 10:12 ` Florian Weimer
2016-11-16 15:55 ` Zack Weinberg [this message]
2016-11-18 15:48 ` Florian Weimer
2016-11-19 17:25 ` Zack Weinberg
2016-11-22 15:09 ` Florian Weimer
2016-11-22 15:30 ` Andreas Schwab
2016-11-22 15:39 ` Florian Weimer
2016-11-22 15:48 ` Zack Weinberg
2016-11-22 15:48 ` Zack Weinberg
2016-11-22 17:42 ` Joseph Myers
2016-11-23 14:09 ` Zack Weinberg
2016-11-24 10:01 ` Florian Weimer
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=0c682496-5c13-b3c5-ff66-0f8923a1d6e3@panix.com \
--to=zackw@panix.com \
--cc=libc-alpha@sourceware.org \
/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).