* Sergey Bugaev: > On Thu, May 18, 2023 at 11:16 PM Joseph Myers <jos...@codesourcery.com> wrote: >> Strictly there are two separate issues: (a) calling an exported symbol >> should be done via a hidden alias, to avoid going via the PLT, and (b) >> functions in a standard namespace should not call names in the user's >> namespace, which requires using a name such as __hurd_thread_self instead >> (which should also be marked hidden to make the call optimally efficient). > > While we're talking about this, could you please say if my > understanding below is correct (and correct me if not)? > > 'foo' is a public symbol, to be used by the user, and also > interposable by the user. Always called via PLT (except from inside > the user's code when redefined inside the executable, in which case > the compiler/linker will see that no PLT is needed), and should not be > called from inside glibc. > > '__foo' is a (public? private? semi-private?) symbol, the user code is > not supposed to use it, but it's exported from libc.so for the benefit > of other glibc code that ends up in different DSOs and still wants to > call the original version even when 'foo' gets interposed. Invoked via > PLT from other DSOs, not invoked from libc.so because of...
__foo may be exported or not. We have some __ symbols that are used by the implementation (so GCC etc.), and probably some that are expected to be used by users. Truely exported symbols have a GLIBC_2.y symbol version, internal exported symbols (usually added for coordination between different shared objects that make up glibc) have a GLIBC_PRIVATE symbol version. Some old internal symbols have GLIBC_2.0 or similar early versions because GLIBC_PRIVATE did not exist then. > '__GI___foo' is a private non-exported symbol created by the > hidden_def/hidden_proto macro being used on '__foo', this is what the > code in libc.so (or: whatever DSO the symbol is hidden_def'ed in) > calls to avoid PLT jumps. Correct. > Q: why '__foo', why not use hidden_def/hidden_proto on the 'foo' directly? > A: that would only work for code that ends up in libc.so (or rather, > the same DSOs as 'foo'), but we still want other code to also call the > non-interposed, original version of 'foo' hidden_def/hidden_proto does not do anything for static linking, given the macros are defined today. It's of course possible to do all this quite differently. Thanks, Florian
