Re: [PATCH 05/18] Open-code the memcpy() at static TLS initialization time.

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

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.