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*
Pardon my blatant ignorance;
libpthread has interceptors?
Best,
Tone Kastlunger
On Wed, Feb 20, 2019 at 10:23 AM Carlos O'Donell <carlos@redhat.com> wrote:
>
> On 2/20/19 3:12 AM, Florian Weimer wrote:
> > * 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).
>
> Yes, that's probably the case.
>
> --
> Cheers,
> Carlos.