This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: pthread sem_open : private glibc functions (__libc*
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Tone Kastlunger <users dot giulietta at gmail dot com>, libc-alpha at sourceware dot org
- Date: Wed, 20 Feb 2019 02:33:55 -0500
- Subject: Re: pthread sem_open : private glibc functions (__libc*
- References: <CAHCc5YXavph5xnbq4Mvh2rwFg976DrobR7XE1Uz4FE_=6w1iBA@mail.gmail.com>
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.
--
Cheers,
Carlos.