[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z2fL-emmeNBoFv9c@voyager>
Date: Sun, 22 Dec 2024 09:21:13 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: struct mq_attr wrong on x32?
Am Sun, Dec 22, 2024 at 12:02:54AM +0100 schrieb Thorsten Glaser:
> On Sat, 21 Dec 2024, Markus Wichmann wrote:
>
> >At this point, since the wrong definitions are already published,
> >translation makes the most sense, of course.
>
> Might not even be needed, as the new and old structures are
> the same in memory, so while it’s an API change (correction)
> it’s not an ABI change, as x32 is little endian.
>
> bye,
> //mirabilos
I think we might be talking past each other. The musl definition of
these structures is a copy of the kernel definition, but substituting
long for "__kernel_long_t". On x32, "long" is a 32-bit type, but
"__kernel_long_t" is a 64-bit type. For that reason, the offsets of all
the fields but the first are off. And the size as well, maybe leading to
memory corruption. And of course, only x32 is affected by this.
In most other cases where "__kernel_long_t" makes an appearance in the
kernel headers, the structures are already arch-dependent (e.g. the SysV
IPC stuff), so adjusting the x32 version for this discrepancy is not an
issue, but the two cases I found here are supposed to be
arch-independent, but aren't.
musl cares about ABI, so we need a translation solution here, and I
don't really see an elegant way that avoids both conditional compilation
and useless translation on the other architectures (where the types
match). Might be conditional compilation is the smaller evil here.
Ciao,
Markus
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.
