This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 05/18] Open-code the memcpy() at static TLS initialization time.
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-alpha at sourceware dot org
- Date: Thu, 10 Mar 2016 10:02:01 +0700
- Subject: Re: [PATCH 05/18] Open-code the memcpy() at static TLS initialization time.
- Authentication-results: sourceware.org; auth=none
- References: <1457445064-7107-1-git-send-email-nix at esperi dot org dot uk> <1457445064-7107-6-git-send-email-nix at esperi dot org dot uk> <20160309224330 dot GE6588 at vapier dot lan> <87y49rkuye dot fsf at esperi dot org dot uk> <20160310022853 dot GH6588 at vapier dot lan>
On 10-03-2016 09:28, Mike Frysinger wrote:
> On 10 Mar 2016 01:00, Nix wrote:
>> On 9 Mar 2016, Mike Frysinger uttered the following:
>>> On 08 Mar 2016 13:50, Nix wrote:
>>>> This one is a bit nasty. Now that we are initializing TLS earlier for
>>>> the stack canary's sake, existing memcpy() implementations become
>>>> problematic. We can use the multiarch implementations, but they might
>>>> not always be present, and even if they are present they might not always
>>>> be in assembler, so might be compiled with stack-protection. We cannot
>>>> use posix/memcpy.c without marking both it and */wordcopy.c as non-stack-
>>>> protected, which for memcpy() of all things seems like a seriously bad
>>>> idea: if any function in glibc should be stack-protected, it's memcpy()
>>>> (though stack-protecting the many optimized assembly versions is not done
>>>> in this patch series).
>>>>
>>>> So we have two real options: hack up the guts of posix/memcpy.c and
>>>> */wordcopy.c so that they can be #included (renamed and declared static)
>>>> inside libc-tls.c, or simply open-code the memcpy(). For simplicity's
>>>> sake, this patch open-codes it, on the grounds that static binaries are
>>>> relatively rare and quasi-deprecated anyway, and static binaries with
>>>> large TLS sections are yet rarer, and not worth the complexity of hacking
>>>> up all the arch-dependent wordcopy files.
>>>
>>> can we utilize _HAVE_STRING_ARCH_memcpy here ? the string includes will
>>> sometimes provide inlined asm versions ...
>>
>> I think so, *if* we can be sure that arches that define
>> _HAVE_STRING_ARCH_memcpy will never expand memcpy() to macros that
>> sometimes call functions, but only to pure inline asm stuff. Since there
>> is only one definer of that (x86), I'm not sure that's guaranteed...
>
> i guess look at the other arch inlines to see what they do. i honestly
> don't know where or how well these APIs are defined.
>
>> + /* sbrk gives us zero'd memory, so we don't need to clear the remainder.
>> +
>> + Use inlined asm implementation if available: otherwise, copy by hand,
>> + because memcpy() is stack-protected and is often multiarch too. */
>> +
>> +#if defined _HAVE_STRING_ARCH_memcpy
>> memcpy (_dl_static_dtv[2].pointer.val, initimage, filesz);
>
> should this also depend on SSP not being enabled ?
> #if defined _HAVE_STRING_ARCH_memcpy || !defined <whatever SSP define>
>
> otherwise, you'd want to use "#ifdef".
> -mike
>
Is _HAVE_STRING_ARCH_memcpy really doing a better job than gcc? I would prefer
to just use the open memcpy and let it optimize it.