From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14929 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: Tue, 12 Nov 2019 18:05:49 +0100 Message-ID: <20191112170549.GH25646@port70.net> References: <20191110010802.GC25646@port70.net> <20191110061409.GM16318@brightrain.aerifal.cx> <20191110120253.GD25646@port70.net> <20191112030150.GQ16318@brightrain.aerifal.cx> <20191112111606.GE25646@port70.net> <20191112163446.GR16318@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="117256"; 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-14945-gllmg-musl=m.gmane.org@lists.openwall.com Tue Nov 12 18:06:10 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 1iUZcH-000U82-Lb for gllmg-musl@m.gmane.org; Tue, 12 Nov 2019 18:06:09 +0100 Original-Received: (qmail 26311 invoked by uid 550); 12 Nov 2019 17:06:02 -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 26290 invoked from network); 12 Nov 2019 17:06:01 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20191112163446.GR16318@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:14929 Archived-At: * Rich Felker [2019-11-12 11:34:46 -0500]: > On Tue, Nov 12, 2019 at 12:16:06PM +0100, Szabolcs Nagy wrote: > > * Rich Felker [2019-11-11 22:01:50 -0500]: > > > On Sun, Nov 10, 2019 at 01:02:53PM +0100, Szabolcs Nagy wrote: > > > > * 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 don't follow that line of reasoning; the alignment would potentially > > > differ, but the layout wouldn't, and that's why I initially suspected > > > they were doing this for alignment. In any case, the only arch without > > > at least 4-byte alignment is m68k, and it's not going to have a 64-bit > > > version. > > > > why would the layout be the same? > > > > uint8_t x; > > uint64_t y; // aligned to 2 bytes > > > > and > > > > uint8_t x; > > uint64_t y; // aligned to 4 bytes > > > > should have different layout (1 vs 3 bytes padding). > > I'm talking about doing it with explicit padding, and thought that's > what we were comparing against, e.g.: > > uint8_t x, __pad[7]; > uint64_t y; ok i reread the discussion and now i'm unsure about the reasoning: v5 discussion: https://marc.info/?l=linux-api&m=154454540314234&w=2 see v6 changelog: https://marc.info/?l=linux-api&m=154472189430098&w=2 it seems the reviewer asked for comments for the paddings, so they were removed to avoid comments? > Any preference on which (also having the aligned, or not)? I'd > probably lean towards omitting it but I don't have a strong opinion on > this. yes, it can be omitted i think if everything uses libc headers consistently. (e.g. if something uses the kernel headers in one tu then it won't be compatible with another tu that uses libc types)