This is the mail archive of the
mailing list for the glibc project.
Re: pthread sem_open : private glibc functions (__libc*
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Tone Kastlunger <users dot giulietta at gmail dot com>, libc-alpha at sourceware dot org
- Date: Wed, 20 Feb 2019 03:23:27 -0500
- Subject: Re: pthread sem_open : private glibc functions (__libc*
- References: <CAHCc5YXavph5xnbq4Mvh2rwFg976DrobR7XE1Uz4FE_=6w1iBA@mail.gmail.com> <email@example.com> <firstname.lastname@example.org>
On 2/20/19 3:12 AM, Florian Weimer wrote:
> * Carlos O'Donell:
>> On 2/19/19 8:26 AM, Tone Kastlunger wrote:
>>> 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.
>> 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).
Yes, that's probably the case.