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

[Nix <nix at esperi dot org dot uk>]

On 10 Mar 2016, Mike Frysinger verbalised:

> On 10 Mar 2016 01:00, Nix wrote:
>> 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.

The only platform that defines *any* string arch operations is x86. None
of those fall back to out-of-line functions at all, even for huge inputs
(which for some functions and some larger inputs strikes me as a
terrible implementation choice, but ah well.)

>> +  /* 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>

Probably a good idea: it makes things less invasive for the common case.
(Though your belief that there is just *one* SSP define is alas untrue:
we'll have to check all three.)

Adding.