[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 10 Nov 2019 13:02:53 +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-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 guess for musl either works, but the current
struct is how it is defined in glibc.
> > struct __ptrace_peeksiginfo_args {
> > @@ -101,6 +107,28 @@ struct __ptrace_seccomp_metadata {
> > uint64_t flags;
> > };
> >
> > +struct __ptrace_syscall_info {
> > + uint8_t op;
>
> Like uint8_t op, __pad[3];
>
> > + uint32_t arch __attribute__((__aligned__(4)));
> > + uint64_t instruction_pointer;
> > + uint64_t stack_pointer;
> > + union {
> > + struct {
> > + uint64_t nr;
> > + uint64_t args[6];
> > + } entry;
> > + struct {
> > + int64_t rval;
> > + uint8_t is_error;
> > + } exit;
> > + struct {
> > + uint64_t nr;
> > + uint64_t args[6];
> > + uint32_t ret_data;
> > + } seccomp;
> > + };
> > +};
> > +
> > long ptrace(int, ...);
>
> Otherwise, the API having reserved-namespace struct names is ugly but
> it seems this is nothing new...
glibc started using this style (i guess not to conflict
with linux uapi, which is often included when ptrace is
used: strace, gdb,..)
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.
