From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: [PATCH 0/6] updates for linux v5.3
Date: Tue, 12 Nov 2019 12:16:06 +0100 [thread overview]
Message-ID: <20191112111606.GE25646@port70.net> (raw)
In-Reply-To: <20191112030150.GQ16318@brightrain.aerifal.cx>
* 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 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).
ok with me.
next prev parent reply other threads:[~2019-11-12 11:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-10 1:08 Szabolcs Nagy
2019-11-10 6:14 ` Rich Felker
2019-11-10 12:02 ` Szabolcs Nagy
2019-11-12 3:01 ` Rich Felker
2019-11-12 5:16 ` Markus Wichmann
2019-11-12 11:16 ` Szabolcs Nagy [this message]
2019-11-12 16:34 ` Rich Felker
2019-11-12 17:05 ` Szabolcs Nagy
2019-11-13 0:06 ` Szabolcs Nagy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191112111606.GE25646@port70.net \
--to=nsz@port70.net \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).