pthread sem_open : private glibc functions (__libc*
Florian Weimer
fweimer@redhat.com
Wed Feb 20 08:12:00 GMT 2019
* Carlos O'Donell:
> On 2/19/19 8:26 AM, Tone Kastlunger wrote:
>> Hi;
>> the sem_open implementation in the pthread library seems to refer to
>> privately defined aliases of some functions of the glibc
>> (__libc_open/cloe, __libc_write for instance).
>>
>> On the other hand, in the same implementation
>> other glibc function calls are addressed via the (usual) public counterparts
>> (for example unlink).
>>
>> I'm puzzled about this "dissonance". Any reason behind int?
>
> It's complicated.
>
> https://www.sourceware.org/glibc/wiki/Style_and_Conventions#Double-underscore_names_for_public_API_functions
>
> In this case it's libpthread calling to libc for unlink and munmap.
>
> So it's easiest to call the public symbol because we know in the
> given standard, POSIX, which defines sem_open, we must also have
> a working unlink and munmap.
>
> So there is no namespace issue, and there is no PLT avoidance needed.
But that's true for open and write as well. I don't know for certain,
but I suspect it's related to the interceptors for open and write in
libpthread (which are still there today, but are not actually needed).
Thanks,
Florian
More information about the Libc-alpha
mailing list