From: Florian Weimer <fweimer@redhat.com>
To: GNU C Library <libc-alpha@sourceware.org>
Subject: Evolution of ELF symbol management
Date: Tue, 18 Oct 2016 09:26:00 -0000 [thread overview]
Message-ID: <9727f95a-df3d-ec11-8c1d-9b7ea6cbcaac@redhat.com> (raw)
In the ancient past, all glibc symbols, including internal ones, were
public. Then came symbol versioning, and hidden symbols.
This did not solve all problems. For static linking, we often have to
mangle symbols so that an implementation of a function in one standard
does not implicitly require the application to be conforming to another
standard (or standard version): the application might define a symbol
which is reserved by the other standard, and we cannot use this function
in the implementation.
For essentially the same reason, we need to mangle references in
non-libc DSOs to libc symbols which are not present in all of the
standards implied by all symbol references to the non-libc DSO.
Symbol versioning does not help here, for two reasons: We do not provide
symbol versions for static builds. For backwards compatibility reasons,
non-versioned symbols interpose all versioned symbols, irrespective of
their version (not just the base definition). The second reason is
important in practice; it is required for interposing malloc.
I think the above sums up the status quo. 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).
Comments?
Thanks,
Florian
next reply other threads:[~2016-10-18 9:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-18 9:26 Florian Weimer [this message]
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
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=9727f95a-df3d-ec11-8c1d-9b7ea6cbcaac@redhat.com \
--to=fweimer@redhat.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).