[PATCH 2/2] linux/aarch64: sync sys/ptrace.h with Linux 4.15

[Szabolcs Nagy]

On 07/02/18 11:01, Dmitry V. Levin wrote:
> On Wed, Feb 07, 2018 at 10:54:08AM +0000, Szabolcs Nagy wrote:
>> On 07/02/18 09:48, Dmitry V. Levin wrote:
>>> On Mon, Jan 01, 2018 at 11:35:41PM +0300, Dmitry V. Levin wrote:
>>>> On Mon, Jan 01, 2018 at 01:43:53AM +0000, Joseph Myers wrote:
>>>>> On Sat, 30 Dec 2017, Dmitry V. Levin wrote:
>>>>>
>>>>>> To implement a proper multilib sys/ptrace.h on aarch64, arm/sys/ptrace.h
>>>>>> has to be used instead of aarch64/sys/ptrace.h with all arm-specific
>>>>>> definitions ifdef'ed.
>>>>>
>>>>> ARM and AArch64 are separate toolchain ports requiring separate compilers.
>>>>> There is no support for multilib headers supporting both in the same
>>>>> header.  (Debian/Ubuntu multiarch configurations put all bits/ and sys/
>>>>> headers in multiarch directory arrangements so could handle having both
>>>>> versions of a sys/ header installed without problems.)
>>>>
>>>> Sure.  My comment is addressed to people who might consider implementing
>>>> multilib headers on aarch64 in the future.
>>>
>>> Any more comments?  Is the change OK?
>>
>> no, multilib header support is not wanted with arm and aarch64,
>> they are separate targets.
> 
> Okay, I can omit this comment.  Is the change itself OK?
> 

yes the change is ok, i was only arguing about the comment, sorry.

>> i thought users of ptrace.h just include the linux asm/ptrace.h
>> anyway, so glibc does not need to track linux uapi.
>> (at least gdb does that in its linux specific code)
> 
> Sadly, this happens sometimes because sys/ptrace.h is used to be out of date.
> However, sys/ptrace.h is still in use, otherwise we wouldn't receive bug
> reports like https://sourceware.org/bugzilla/show_bug.cgi?id=22433
> and https://sourceware.org/bugzilla/show_bug.cgi?id=22807
> 

i see.