Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260312005414.GQ3520958@port70.net>
Date: Thu, 12 Mar 2026 01:54:14 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: Rich Felker <dalias@...c.org>
Cc: Ariadne Conill <ariadne@...eferenced.org>,
	James Y Knight <jyknight@...gle.com>, musl@...ts.openwall.com,
	Thorsten Glaser <tg@...bsd.de>
Subject: Re: Question about flexible array

* Rich Felker <dalias@...c.org> [2026-03-11 15:29:57 -0400]:
> On Wed, Mar 11, 2026 at 11:45:42AM -0700, Ariadne Conill wrote:
> > Another problem is that some programs want to inspect the context (we have
> > seen this in DRM modules for example with gcompat), so they may be expecting
> > floating point data in the place it would normally be.
> > 
> > This is another reason why I haven't bothered making libucontext hard-float
> > on LoongArch yet.
> > 
> > In practice, it hasn't really mattered yet anyway.
> 
> My leaning would be to fix the structure definition to have space to
> store the fp registers in the right place rather than stuffing them
> somewhere else, but one way or another it needs to be fixed.

then we need to add 304bytes at the end of the struct
(16byte header + 32*8 fp reg + 16byte fenv + 16byte end
header), but even then

*p = *q;

can be wrong: the fp ctx may not be the first in the
kernel extension list or the list can be shorter.

so even if we match the layout, the kernel sigcontext
cannot be copied via the libc type, so in practice
the types cannot be passed around interchangably.

if we do the layout match i'd add a few extra bytes
for future changes (e.g. +64byte), because there are
a few extra bytes in jmpbuf so it's possible to add
callee saved state in the future without abi break.

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.