This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] arm: Implement memcpy ifunc selection in C
On 06/10/2017 20:05, Joseph Myers wrote:
> On Fri, 6 Oct 2017, Adhemerval Zanella wrote:
>
>> This patch refactor ARM memcpy ifunc selector to a C implementation.
>> No functional change is expected, including ifunc resolution rules.
>>
>> To avoid build issues with mainline GCC which set no default gnu
>> indirect function support for ARM (--enable-gnu-indirect-function)
>> two fixes are added:
>>
>> 1. The new macro arm_libc_ifunc_hidden_def is redefined using
>> direct asm assembly directives instead of function attributes.
>> This avoid the incompatbile types for a symbol and its alias.
>>
>> 2. A new macro NO_MEM_INTERAL_SYM_HACKS is added on symbol-hacks
>> and defined on arm ifunc objects. It avoids the symbol
>> definition loop because compiler might emit the hacks for first
>> fix before the ifunc function definition itself.
>
> As a general principle, I don't think we should be checking in workarounds
> for defects in unreleased GCC versions (this is not specific to this
> particular issue - it means more generally that if you see a warning
> building with mainline GCC, you need to consider whether that warning is
> buggy before applying glibc changes to avoid the warning).
>
> That is, we should fix the default in GCC mainline and then propose glibc
> changes that do not involve such workarounds. (Arguably the default
> should be to support the attribute for all architectures, to avoid future
> issues when new architectures gain binutils support for IFUNCs after the
> GCC 8 release.)
There are two different issues here:
1. My understanding if for 1. is for gcc mainline we are aiming to *not*
support glibc builds support for gnu indirection function
(--enable-gnu-indirect-function). I think this is too restrictive and
since it is possible to support glibc build whether gcc has it supports
should not prevent this specific support on glibc.
2. The 2. is indeed a workaround for mainline issue and I agree we should
avoid pushing fixes for this issues on glibc. I will work on it.