This is the mail archive of the
mailing list for the glibc project.
Re: Document __foo symbol variants and their uses in the library sources.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 23 Apr 2014 14:59:58 +0000
- Subject: Re: Document __foo symbol variants and their uses in the library sources.
- Authentication-results: sourceware.org; auth=none
- References: <534B9019 dot 8080406 at redhat dot com>
On Mon, 14 Apr 2014, Carlos O'Donell wrote:
> In response to some questions on libc-help here is a
> first attempt at documenting some of the conventions
> behind calling the double-underscore versions of the
> public API functions from within the library (to avoid
> the PLT indirect and maintain internal consistency).
> I would appreciate any review.
That appears to confuse two things.
* hidden_proto / hidden_def (etc.) are about PLT avoidance (and may also
enable better code generation in some cases because the compiler knows
it's calling a hidden symbol which must be in the same library). They may
be used both on names starting with __ and names that aren't so-prefixed.
They are irrelevant when a function in one library is calling a function
in another library.
* __-prefixed names are about being namespace-clean, where the user calls
a function in one standard and that function internally uses a function
from another standard, or not in any standard. In such cases, you need to
use __-prefixed names, whether or not the function being called is in the
same library, to avoid conflicts with the user's own symbols in the static
linking case. If the function called is in another library, the
__-prefixed function *also* needs to be exported at GLIBC_PRIVATE so that
the call can work in the dynamic linking case - unless there's a reason
for it to be exported at a public symbol version. (For example, if a
macro definition of a public function in an installed header uses the
__-prefixed function, or libstdc++ should use it, or redirection for
_FILE_OFFSET_BITS=64 should use it, then it may be necessary to export at
a public version, in which case you don't need a redundant GLIBC_PRIVATE
export.) And if the function is in the same library you should still use
hidden_proto / hidden_def.
Joseph S. Myers