From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
To: Stafford Horne <shorne@gmail.com>
Cc: GLIBC patches <libc-alpha@sourceware.org>,
Linux OpenRISC <linux-openrisc@vger.kernel.org>
Subject: Re: [PATCH 1/4] or1k: Fix Linux user space signal ABI
Date: Wed, 20 Mar 2024 17:12:08 -0300 [thread overview]
Message-ID: <907e694a-b3df-429c-acb1-28dfc2a7f211@linaro.org> (raw)
In-Reply-To: <ZfrvHIfPjF2GHnXL@antec>
On 20/03/24 11:13, Stafford Horne wrote:
> On Wed, Mar 20, 2024 at 10:24:15AM -0300, Adhemerval Zanella Netto wrote:
>>
>>
>> On 19/03/24 18:42, Stafford Horne wrote:
>>> The OpenRISC sigcontext structure has always been defined as:
>>>
>>> struct user_regs_struct {
>>> /* GPR R0-R31... */
>>> unsigned long gpr[32];
>>> unsigned long pc;
>>> unsigned long sr;
>>> };
>>>
>>> struct sigcontext {
>>> struct user_regs_struct regs; /* needs to be first */
>>> unsigned long oldmask; /* unused */
>>> };
>>>
>>> With Linux v6.8 we added FPU support and repurposed the oldmask
>>> to use for the FPCSR (floating point control status register).
>>>
>>> struct sigcontext {
>>> struct user_regs_struct regs; /* needs to be first */
>>> union {
>>> unsigned long fpcsr;
>>> unsigned long oldmask; /* unused */
>>> };
>>> };
>>>
>>> The definition of mcontext_t was always missing the extra space for
>>> oldmask. This patch adds the field __fpcsr to mcontext_t to fix the ABI
>>> mismatch between glibc and Linux.
>>
>> This is strictly an ABI break, this won't make the swapcontext functions
>> to fail (since they are not update to take in consideration the new field),
>> but it also means that the fpcsr won't be save/restore and the application
>> can potentially read uninitialized values.
>>
>> But I take that the fpu support will be a new ABI, so I suggest to fix
>> when you add it (along with proper support to context functions).
>
> OK, I got it. I will post this when the hard float code is added and also fixup
> swapcontext etc to populated it correctly with or without hard float.
>
> Note there is broken ABI already, as programs will not be able to access sigmask
> if needed due to:
>
> Linux definition:
>
> struct ucontext {
> unsigned long uc_flags;
> struct ucontext *uc_link;
> stack_t uc_stack;
> struct sigcontext uc_mcontext; <-- size differs between glibc and linux
> sigset_t uc_sigmask; <-- won't be able to access if needed
> };
> > But still I will leave as is for now. This hasn't cause any issues as far as I
> have seen so far.
But even changing the uc_sigmask offset on ucontext would require versioned
context functions. Usually to access the signal frame ucontex_t, it is safer
to user the linux UAPI definition instead of the libc one.
next prev parent reply other threads:[~2024-03-20 20:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-19 21:42 [PATCH 0/4] OpenRISC fixes for 2.39 Stafford Horne
2024-03-19 21:42 ` [PATCH 1/4] or1k: Fix Linux user space signal ABI Stafford Horne
2024-03-20 13:24 ` Adhemerval Zanella Netto
2024-03-20 14:13 ` Stafford Horne
2024-03-20 20:12 ` Adhemerval Zanella Netto [this message]
2024-03-19 21:42 ` [PATCH 2/4] or1k: Update libm test ulps Stafford Horne
2024-03-19 21:42 ` [PATCH 3/4] or1k: Only define fpu rouding and exceptions with hard-float Stafford Horne
2024-03-19 21:42 ` [PATCH 4/4] or1k: Add prctl wrapper to unwrap variadic args Stafford Horne
2024-03-20 13:28 ` Adhemerval Zanella Netto
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
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=907e694a-b3df-429c-acb1-28dfc2a7f211@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=libc-alpha@sourceware.org \
--cc=linux-openrisc@vger.kernel.org \
--cc=shorne@gmail.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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).