Message ID | 20171230000934.GB11705@altlinux.org |
---|---|
State | New |
Headers | show |
Series | [1/2] linux/arm: sync sys/ptrace.h with Linux 4.15 [BZ #22433] | expand |
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.)
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.
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?
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)
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.
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
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.
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