[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/20/2016 04:05 PM, Stefan Liebler wrote:
> 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
>>>
>>
>>
>
>