From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14923 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 0/6] updates for linux v5.3 Date: Sun, 10 Nov 2019 01:14:09 -0500 Message-ID: <20191110061409.GM16318@brightrain.aerifal.cx> References: <20191110010802.GC25646@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="21519"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14939-gllmg-musl=m.gmane.org@lists.openwall.com Sun Nov 10 07:14:28 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iTgUU-0005T2-Ch for gllmg-musl@m.gmane.org; Sun, 10 Nov 2019 07:14:26 +0100 Original-Received: (qmail 1862 invoked by uid 550); 10 Nov 2019 06:14:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1842 invoked from network); 10 Nov 2019 06:14:22 -0000 Content-Disposition: inline In-Reply-To: <20191110010802.GC25646@port70.net> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14923 Archived-At: On Sun, Nov 10, 2019 at 02:08:02AM +0100, Szabolcs Nagy wrote: > >From 560fd1ebe616fd59c0abcaf86bec6109bfcd2141 Mon Sep 17 00:00:00 2001 > From: Szabolcs Nagy > Date: Sun, 3 Nov 2019 22:45:05 +0000 > Subject: [PATCH 4/6] sys/ptrace.h: add PTRACE_GET_SYSCALL_INFO from linux v5.3 > > ptrace API to get details of the syscall the tracee is blocked in, see > > linux commit 201766a20e30f982ccfe36bebfad9602c3ff574a > ptrace: add PTRACE_GET_SYSCALL_INFO request > > the align attribute was used to keep the layout the same across targets > e.g. on m68k uint32_t is 2 byte aligned, this helps with compat ptrace. Can you explain the motivation for this? At first I thought it was for overall alignment of the structure, but there are also 64-bit members that aren't aligned, so presumably this is only to get padding after the initial uint8_t? If so, just add 3 explicit padding members: > --- > include/sys/ptrace.h | 28 ++++++++++++++++++++++++++++ > 1 file changed, 28 insertions(+) > > diff --git a/include/sys/ptrace.h b/include/sys/ptrace.h > index 229e1f3d..2a868093 100644 > --- a/include/sys/ptrace.h > +++ b/include/sys/ptrace.h > @@ -41,6 +41,7 @@ extern "C" { > #define PTRACE_SETSIGMASK 0x420b > #define PTRACE_SECCOMP_GET_FILTER 0x420c > #define PTRACE_SECCOMP_GET_METADATA 0x420d > +#define PTRACE_GET_SYSCALL_INFO 0x420e > > #define PT_READ_I PTRACE_PEEKTEXT > #define PT_READ_D PTRACE_PEEKDATA > @@ -88,6 +89,11 @@ extern "C" { > > #define PTRACE_PEEKSIGINFO_SHARED 1 > > +#define PTRACE_SYSCALL_INFO_NONE 0 > +#define PTRACE_SYSCALL_INFO_ENTRY 1 > +#define PTRACE_SYSCALL_INFO_EXIT 2 > +#define PTRACE_SYSCALL_INFO_SECCOMP 3 > + > #include > > struct __ptrace_peeksiginfo_args { > @@ -101,6 +107,28 @@ struct __ptrace_seccomp_metadata { > uint64_t flags; > }; > > +struct __ptrace_syscall_info { > + uint8_t op; Like uint8_t op, __pad[3]; > + uint32_t arch __attribute__((__aligned__(4))); > + uint64_t instruction_pointer; > + uint64_t stack_pointer; > + union { > + struct { > + uint64_t nr; > + uint64_t args[6]; > + } entry; > + struct { > + int64_t rval; > + uint8_t is_error; > + } exit; > + struct { > + uint64_t nr; > + uint64_t args[6]; > + uint32_t ret_data; > + } seccomp; > + }; > +}; > + > long ptrace(int, ...); Otherwise, the API having reserved-namespace struct names is ugly but it seems this is nothing new... Rich