Re: [PATCH] Linux: Consolidate auxiliary vector parsing (redo)

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 14/02/2022 09:16, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> I still think this approach is still fragile since we don't how if this
>> will be the only optimization option gcc will make loops to memset. We 
>> already have a similar problem on _dl_start, but it is slight different
>> since the clear memory should be done before self-relocation. Also for 
>> memset.c itself there is no much we can do, so we need to resort on 
>> -fno-tree-loop-distribute-patterns.
>>
>> However in this case I think it would be better to avoid hacking the
>> compiler and expect it does not generate broken code and instead assume
>> memset *might* be generate and work around it.  We already have the
>> hack on sysdeps/generic/symbol-hacks.h, so I think we should do something
>> similiar:
>>
>>   1. Add a __memset_generic internal symbol on all ports to avoid the
>>      iFUNC plt (which seems to be cause of this issue).
>>
>>   2. Add a symbol redirection to call such symbol when required (most
>>      likely in the dl-start.h as H.J has suggested.
>>
>> So we don't need to handle this specific issue everytime we hack into
>> the loader code.
> 
> But this isn't a new problem, right?
> 
> I also don't think an assembler-based symbol redirect is more portable
> than -fno-tree-loop-distribute-patterns.  We need to build these parts
> with -ffreestanding, and we need a portable way (across GCC and Clang)
> to redirect the four required functions ('memcpy', 'memmove', 'memset'
> and 'memcmp', according to the GCC manual).

I don't think -ffreestanding will help much in this specific issue.  The
problem is mainly that for some architectures, memcpy, memmove, memset,
and memcmp might be implemented as a iFUNC and it might no be relocated
at the time of the call.  At least redirecting the calls to internal
symbols avoid this specific issue.