From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14924 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 0/6] updates for linux v5.3 Date: Sun, 10 Nov 2019 13:02:53 +0100 Message-ID: <20191110120253.GD25646@port70.net> References: <20191110010802.GC25646@port70.net> <20191110061409.GM16318@brightrain.aerifal.cx> 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="50399"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-14940-gllmg-musl=m.gmane.org@lists.openwall.com Sun Nov 10 13:03:12 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 1iTlvy-000CyM-7Y for gllmg-musl@m.gmane.org; Sun, 10 Nov 2019 13:03:10 +0100 Original-Received: (qmail 1603 invoked by uid 550); 10 Nov 2019 12:03:06 -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 1582 invoked from network); 10 Nov 2019 12:03:05 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20191110061409.GM16318@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:14924 Archived-At: * Rich Felker [2019-11-10 01:14:09 -0500]: > 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: the original linux struct had padding but during review they changed it to aligned because some linux devs thought that made the intent clearer or more future proof (e.g. what if uint64_t is also 2byte aligned, but on the 64bit version of the same architecture it's 8byte aligned, then compat ptrace would not work because one abi would have padding and the other wouldnt). i guess for musl either works, but the current struct is how it is defined in glibc. > > 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... glibc started using this style (i guess not to conflict with linux uapi, which is often included when ptrace is used: strace, gdb,..)