[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191112170549.GH25646@port70.net>
Date: Tue, 12 Nov 2019 18:05:49 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 0/6] updates for linux v5.3
* Rich Felker <dalias@...c.org> [2019-11-12 11:34:46 -0500]:
> On Tue, Nov 12, 2019 at 12:16:06PM +0100, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@...c.org> [2019-11-11 22:01:50 -0500]:
> > > On Sun, Nov 10, 2019 at 01:02:53PM +0100, Szabolcs Nagy wrote:
> > > > * Rich Felker <dalias@...c.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@...t70.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)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
