[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Nov 2019 22:01:50 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 0/6] updates for linux v5.3
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.
> i guess for musl either works, but the current
> struct is how it is defined in glibc.
Generally in musl we prefer not using extensions in public headers
except where the effect can be achieved in no other way. Only m68k is
affected by using the forced alignment here, but I don't think there's
any strong reason to prefer one way or the other. I think I'd want to
include the padding even if we do also include
_Alignas/alignas/__attribute__((__aligned__)) (dependent on language
version macros) so that in the fallback case the layout is still
correct even if the alignment isn't (on m68k only).
Rich
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.
