This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3 1/3] Consolidate vDSO macros and usage
- From: Nathan Lynch <Nathan_Lynch at codesourcery dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 21 May 2015 11:03:59 -0500
- Subject: Re: [PATCH v3 1/3] Consolidate vDSO macros and usage
- Authentication-results: sourceware.org; auth=none
- References: <5550FEF5 dot 3080202 at linaro dot org> <555B7625 dot 1070801 at codesourcery dot com> <555B93A7 dot 1020208 at linaro dot org>
On 05/19/2015 02:48 PM, Adhemerval Zanella wrote:
>
>
> On 19-05-2015 14:43, Nathan Lynch wrote:
>> On 05/11/2015 02:11 PM, Adhemerval Zanella wrote:
>>> This patch consolidate the Linux vDSO define and usage across all ports
>>> that uses it. The common vDSO definitions and calling through
>>> {INLINE/INTERNAL}_VSYSCALL macros are moved to a common header
>>> sysdep-vdso.h and vDSO name declaration and prototype is defined
>>> using a common macro.
>>>
>>> Also PTR_{MANGLE,DEMANGLE} is added to ports that does not use them
>>> for vDSO calls (aarch64, powerpc, s390, and tile) and thus it will
>>> reflect in code changes. For ports that already implement pointer
>>> mangling/demangling in vDSO system (i386, x32, x86_64) this patch
>>> is mainly a code refactor.
>>>
>>> Checked on x32, x86_64, x32, ppc64le, and aarch64. Ok to apply?
>>>
>>> Changes from previous version:
>>>
>>> - Rename INTERNAL_VSYSCALL_NCS to INTERNAL_VSYSCALL_CALL on all
>>> ports.
>>
>> I believe this series leaves a stray definition of INTERNAL_VSYSCALL_NCS
>> in aarch64:
>>
>> /* List of system calls which are supported as vsyscalls. */
>> # define HAVE_CLOCK_GETRES_VSYSCALL 1
>> # define HAVE_CLOCK_GETTIME_VSYSCALL 1
>> # define HAVE_GETTIMEOFDAY_VSYSCALL 1
>>
>> # define INTERNAL_VSYSCALL_NCS(funcptr, err, nr, args...) \
>>
>> Otherwise it looks fine to me and I have reworked the ARM VDSO support
>> patch on top of it.
>
> Indeed, I will remove it. Any more concerns about this patch?
I have none. Thanks for doing this refactoring.