This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add private_function for private functions within glibc [BZ #21598]
On 08/10/2017 03:01 PM, H.J. Lu wrote:
> On Thu, Aug 10, 2017 at 5:49 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 08/10/2017 02:44 PM, H.J. Lu wrote:
>>
>>> It is OK to use __attribute__ ((regparm (3))) with CET as long as the
>>> function is hidden. We need to at least keep __attribute__ ((regparm (1)))
>>> on ___tls_get_addr since it is the part of TLS ABI and we may have to
>>> support __attribute__ ((regparm (3))) for lazy binding when CET is disabled
>>> forever. Remove it from glibc doesn't buy us much.
>>
>> It buys us peace of mind for those of us who do not work on i386 because
>> internal_function mismatches are a constant source of i386 build
>> failures. I want to get rid of it because I think its presence is a
>> poor trade-off for the project as a whole.
>>
>
> That is fine with me then.
>
> FWIW, last time when I tried it, I gave up after many segfaults :-(.
> The list of places I remembered:
>
> 1. _dl_init.
> 2. _dl_fixup
> 3. TLS lookup functions.
I posted my first set of cleanup patches. The first round targets
functions which have a hidden alias because my GCC hack to detect ABI
mismatches is not compatible with them at the source level. These
functions also fail to match the guidelines for internal_function
because they are definitely called across DSO boundaries, so they are a
good candidate for removal of the attribute.
For __fortify_fail, I had to adjust the call from the assembly
implementation in __longjmp_chk.
Thanks,
Florian