| Message ID | 20171230000934.GB11705@altlinux.org |
|---|---|
| State | New, archived |
| Headers |
Received: (qmail 127281 invoked by alias); 30 Dec 2017 00:09:38 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 127268 invoked by uid 89); 30 Dec 2017 00:09:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.7 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_NUMSUBJECT, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*MI:sk:2017123 X-HELO: vmicros1.altlinux.org Date: Sat, 30 Dec 2017 03:09:34 +0300 From: "Dmitry V. Levin" <ldv@altlinux.org> To: libc-alpha@sourceware.org Subject: [PATCH 2/2] linux/aarch64: sync sys/ptrace.h with Linux 4.15 Message-ID: <20171230000934.GB11705@altlinux.org> Mail-Followup-To: libc-alpha@sourceware.org References: <20171230000806.GA11705@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171230000806.GA11705@altlinux.org> |
Commit Message
Dmitry V. Levin
Dec. 30, 2017, 12:09 a.m. UTC
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(-)
Comments
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