Re: [PATCH 0/6] updates for linux v5.3

[Szabolcs Nagy <nsz@port70.net>]

* Rich Felker <dalias@libc.org> [2019-11-12 11:34:46 -0500]:
> On Tue, Nov 12, 2019 at 12:16:06PM +0100, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@libc.org> [2019-11-11 22:01:50 -0500]:
> > > On Sun, Nov 10, 2019 at 01:02:53PM +0100, Szabolcs Nagy wrote:
> > > > * Rich Felker <dalias@libc.org> [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 <nsz@port70.net>
> > > > > > 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)