Date: Tue, 12 Nov 2019 11:34:46 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: [PATCH 0/6] updates for linux v5.3 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; uint64_t y; > > > 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. 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. 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.