Re: [hurd,commited] hurd: Avoid more libc.so local PLTs

[Zack Weinberg <zackw at panix dot com>]

On Tue, Apr 3, 2018 at 5:55 PM, Samuel Thibault
<samuel.thibault@ens-lyon.org> wrote:
> H.J. Lu, on mar. 03 avril 2018 14:41:27 -0700, wrote:
>> On Tue, Apr 3, 2018 at 2:24 PM, Samuel Thibault
>> <samuel.thibault@ens-lyon.org> wrote:
>> > H.J. Lu, on mar. 03 avril 2018 14:16:50 -0700, wrote:
>> >> On Tue, Apr 3, 2018 at 2:07 PM, Samuel Thibault
>> >> <samuel.thibault@ens-lyon.org> wrote:
>> >> > Hello,
>> >> >
>> >> > H.J. Lu, on mar. 03 avril 2018 12:26:33 -0700, wrote:
>> >> >> __libc_longjmp and __libc_siglongjmp are private external functions provided for
>> >> >> libpthread.  They should never be called inside libc.
>> >> >
>> >> > I'm sorry for asking, but are these conventions documented somewhere?
>> >> > These look like magic to me otherwise:
>> >>
>> >> I don't believe they are well documented.
>> >
>> > Ok, then I need an answer to my question:
>> >
>> >> > why shouldn't they ever be called from libc?
>> >
>> > The existing hurd code does use them for catching signals, so I need to
>> > know how to fix it.
>>
>> Use something similar to
>>
>> libc_hidden_proto (_setjmp)
>> libc_hidden_proto (__sigsetjmp)
>
> So I'd just add hidden protos & defs to longjmp and siglongjmp?

Right, except it has to be the __ variety for siglongjmp because that
function is not in C89.

These are the rules as I understand them:

First, any internal call to a function that is not in C89 probably has
to call a __-prefixed name, or you will fail the checknamespace tests.
The principle here is that a strictly-conforming C89 program _could
have_ defined the unprefixed version of that name and we don't want
that to interfere.  This is true even if the unprefixed name has a
hidden_proto annotation, because those have no effect on static
linkage.  There are exceptions to this rule but I do not understand
them well enough to explain them.

Second, if an internal function is defined in libc, and should only
ever be called from within libc, then it should be given a name that
starts with __ but not with __libc_, and should be declared with
attribute_hidden on its prototype, but does not need
hidden_def/hidden_proto annotations.  This is the simple case for
avoiding unnecessary calls through the PLT.

Third, if an internal function is defined in libc and called from both
inside and outside libc, but still not by applications, you declare it
*without* attribute_hidden on its prototype and use libc_hidden_def
and libc_hidden_proto, and you still use a name that starts with __
but not with __libc_.  That bypasses the PLT for internal calls but
leaves the __-name callable from outside libc.  (It may also be
necessary to add the function to a GLIBC_PRIVATE section of a Versions
file.)

The names that start with __libc_ are needed in even more unusual
cases, such as when functions need to be defined in both libc and
libpthread.  I am actually trying to clean this up right now and it is
an ungodly mess.

libhurd and libgnumach are lower-level than libc, IIUC, so the most
important thing for them is the first principle: make sure not to
stomp on the application namespace in static linkage.  You can decide
how important PLT bypassing is to you.

zw