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

login
register
mail settings
Submitter Dmitry Levin
Date Dec. 30, 2017, 12:09 a.m.
Message ID <20171230000934.GB11705@altlinux.org>
Download mbox | patch
Permalink /patch/25145/
State New
Headers show

Comments

Dmitry Levin - Dec. 30, 2017, 12:09 a.m.
Remove compat-specific constants that were never exported by kernel
headers under these names.  Before linux commit v3.7-rc1~16^2~1 they
were exported with COMPAT_ prefix, and after that commit they are not
exported at all.

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.

* sysdeps/unix/sysv/linux/aarch64/sys/ptrace.h (__ptrace_request):
Remove arm-specific PTRACE_GET_THREAD_AREA, PTRACE_GETHBPREGS,
and PTRACE_SETHBPREGS.
---
 ChangeLog                                    | 4 ++++
 sysdeps/unix/sysv/linux/aarch64/sys/ptrace.h | 8 --------
 2 files changed, 4 insertions(+), 8 deletions(-)
Joseph Myers - Jan. 1, 2018, 1:43 a.m.
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.)
Dmitry Levin - Jan. 1, 2018, 8:35 p.m.
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.
Dmitry Levin - Feb. 7, 2018, 9:48 a.m.
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?
Szabolcs Nagy - Feb. 7, 2018, 10:54 a.m.
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.

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)
Szabolcs Nagy - Feb. 7, 2018, 10:58 a.m.
On 30/12/17 00:09, Dmitry V. Levin wrote:
> Remove compat-specific constants that were never exported by kernel
> headers under these names.  Before linux commit v3.7-rc1~16^2~1 they
> were exported with COMPAT_ prefix, and after that commit they are not
> exported at all.
> 
> 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.
> 

this comment is unnecessary.

> * sysdeps/unix/sysv/linux/aarch64/sys/ptrace.h (__ptrace_request):
> Remove arm-specific PTRACE_GET_THREAD_AREA, PTRACE_GETHBPREGS,
> and PTRACE_SETHBPREGS.
> ---
>   ChangeLog                                    | 4 ++++
>   sysdeps/unix/sysv/linux/aarch64/sys/ptrace.h | 8 --------
>   2 files changed, 4 insertions(+), 8 deletions(-)
> 

with that OK to commit.
Dmitry Levin - Feb. 7, 2018, 11:01 a.m.
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?

> 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
Szabolcs Nagy - Feb. 7, 2018, 11:54 a.m.
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.

Patch

diff --git a/sysdeps/unix/sysv/linux/aarch64/sys/ptrace.h b/sysdeps/unix/sysv/linux/aarch64/sys/ptrace.h
index 111d54e..f02b167 100644
--- a/sysdeps/unix/sysv/linux/aarch64/sys/ptrace.h
+++ b/sysdeps/unix/sysv/linux/aarch64/sys/ptrace.h
@@ -78,18 +78,10 @@  enum __ptrace_request
   PTRACE_DETACH = 17,
 #define PT_DETACH PTRACE_DETACH
 
-  PTRACE_GET_THREAD_AREA = 22,
-
   /* Continue and stop at the next entry to or return from syscall.  */
   PTRACE_SYSCALL = 24,
 #define PT_SYSCALL PTRACE_SYSCALL
 
-  /* Get all hardware breakpoint registers.  */
-  PTRACE_GETHBPREGS = 29,
-
-  /* Set all hardware breakpoint registers.  */
-  PTRACE_SETHBPREGS = 30,
-
   /* Set ptrace filter options.  */
   PTRACE_SETOPTIONS = 0x4200,
 #define PT_SETOPTIONS PTRACE_SETOPTIONS