[PING][PATCH 1/8] Use gcc attribute ifunc in libc_ifunc macro instead of inline assembly due to false debuginfo.

[Stefan Liebler]

PING

On 07/12/2016 04:57 PM, Stefan Liebler wrote:
> PING
>
> see latest patches:
>
> [PATCH 1/8] Use gcc attribute ifunc in libc_ifunc macro instead of
> inline assembly due to false debuginfo.
> (This alters ppc and common code!)
> https://www.sourceware.org/ml/libc-alpha/2016-07/msg00093.html
>
> [PATCH 2/8] s390: Refactor ifunc resolvers due to false debuginfo.
> https://www.sourceware.org/ml/libc-alpha/2016-07/msg00092.html
>
> [PATCH 3/8] i386, x86: Use libc_ifunc macro for time, gettimeofday.
> https://www.sourceware.org/ml/libc-alpha/2016-07/msg00091.html
>
> [PATCH 4/8] ppc: Use libc_ifunc macro for time, gettimeofday.
> https://www.sourceware.org/ml/libc-alpha/2016-06/msg00900.html
>
> [PATCH 5/8] Use libc_ifunc macro for clock_* symbols in librt.
> https://www.sourceware.org/ml/libc-alpha/2016-07/msg00090.html
>
> [PATCH 6/8] Use libc_ifunc macro for system in libpthread.
> https://www.sourceware.org/ml/libc-alpha/2016-07/msg00097.html
>
> [PATCH 7/8] Use libc_ifunc macro for vfork in libpthread.
> https://www.sourceware.org/ml/libc-alpha/2016-07/msg00098.html
>
> [PATCH 8/8] Use libc_ifunc macro for siglongjmp, longjmp in libpthread.
> https://www.sourceware.org/ml/libc-alpha/2016-07/msg00095.html
>
>
> Hint:
> These patches won't be commited before glibc 2.24 release.
> The patch "[PATCH 03/14 v7] Do not stack-protect ifunc resolvers."
> (https://www.sourceware.org/ml/libc-alpha/2016-07/msg00174.html) depends
> on this series.
>
> On 07/06/2016 01:45 PM, Florian Weimer wrote:
>> On 07/04/2016 03:44 PM, Stefan Liebler wrote:
>>>> These changes (i.e. patch 1/8) look reasonable to me.  Perhaps wait
>>>> another day if someone else objects.
>>> Do I have to wait for an explicit okay from intel/power maintainer?
>>
>> 1/8 is power-only, and I assumed that you could deal with this question
>> internally. :)
>>
>> The x86 changes need more substantial review from someone more familiar
>> with this part of glibc, I think.
>>
>> Florian
>>
>
>