From: Andrew Burgess <aburgess@redhat.com>
To: Matthieu Longo <matthieu.longo@arm.com>, gdb-patches@sourceware.org
Cc: Luis Machado <luis.machado@amd.com>,
Luis Machado <luis.machado.foss@gmail.com>,
Thiago Jung Bauermann <thiago.bauermann@linaro.org>,
Srinath Parvathaneni <srinath.parvathaneni@arm.com>,
"Maciej W . Rozycki" <macro@orcam.me.uk>,
Andreas Schwab <schwab@suse.de>,
Matthieu Longo <matthieu.longo@arm.com>
Subject: Re: [PATCH v5] gdb: align siginfo_t with the Linux kernel definition
Date: Fri, 04 Sep 2026 20:49:41 +0100 [thread overview]
Message-ID: <87zexwre3u.fsf@redhat.com> (raw)
In-Reply-To: <8733vprn3e.fsf@redhat.com>
Andrew Burgess <aburgess@redhat.com> writes:
> Matthieu Longo <matthieu.longo@arm.com> writes:
>
>> GDB's current definition of siginfo_t is missing many fields present in
>> the Linux kernel definition [1].
>>
>> These fields are useful for providing detailed, user-friendly diagnostics
>> when a fault occurs. Some new AArch64 extensions, such as Permission
>> Overlay Enhancement used to implement Protection Keys [2], require the
>> debugger to inspect 'si_pkey' alongside 'si_addr' to help the user identify
>> the problematic key.
>>
>> This patch aligns GDB's definition of the __sifields._sigfault member of
>> siginfo_t with the definition from the Linux kernel master branch.
>>
>> To avoid hardcoding the field access paths throughout the codebase, this
>> patch also introduces compile-time accessors for the siginfo_t attributes,
>> centralizing their definitions in a single location and making future
>> updates easier.
>>
>> Finally, extend the testsuite to verify access to the new si_pkey field
>> and its preservation when modifying $_siginfo and when reading core files.
>> The tests in siginfo-obj.exp rely on the siginfo_t definition provided by
>> glibc's <signal.h>, which does not yet expose all of the fields present in
>> the kernel definition. As a result, the tests cannot exercise every newly
>> added field and therefore focus on si_pkey, the field motivating this change.
>> The test validates that GDB can read and modify the field correctly; it does
>> not attempt to generate a real protection-key fault.
>
> Hi Matthieu,
>
> Please see this message:
>
> https://sourceware.org/pipermail/bunsen/2026q3/001504.html
>
> This is an LLM generated analysis of this patch which makes the claim
> that si_pkey is not accessible at the glibc level on every
> architecture.
>
> I tried on a couple of compiler farm boxes, but ran into some TCL
> version issues so wasn't able to actually make-check, but on a ppc box,
> if I try to compile gdb.base/siginfo-obj.c manually I get:
>
> $ gcc -o siginfo-obj siginfo-obj.c
> siginfo-obj.c: In function ‘handler’:
> siginfo-obj.c:38:31: error: ‘siginfo_t’ has no member named ‘si_pkey’
> unsigned int ssi_pkey = info->si_pkey;
> ^
>
> This test file did compile before commit 9c99987237dcaca0c6c493d6a.
>
> It would be great if you could take a look at this. Should the si_pkey
> parts of the test be optional maybe?
Found some time to look at this again. I suspect the compile farm
machine I tried is just old. I tried a more up to date machine, and
this all compiled fine.
I suspect we're OK with this test just not working on older machines.
Sorry for the noise.
Thanks,
Andrew
prev parent reply other threads:[~2026-09-04 19:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 12:32 Matthieu Longo
2026-08-03 8:23 ` Matthieu Longo
2026-08-12 21:55 ` Luis
2026-08-12 19:08 ` Simon Marchi
2026-08-13 14:48 ` Matthieu Longo
2026-08-13 15:49 ` Simon Marchi
2026-08-14 10:05 ` Matthieu Longo
2026-08-17 16:59 ` Simon Marchi
2026-08-17 9:33 ` Matthieu Longo
2026-08-17 16:42 ` Simon Marchi
2026-08-17 21:37 ` Matthieu Longo
2026-09-04 16:35 ` Andrew Burgess
2026-09-04 19:49 ` Andrew Burgess [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zexwre3u.fsf@redhat.com \
--to=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado.foss@gmail.com \
--cc=luis.machado@amd.com \
--cc=macro@orcam.me.uk \
--cc=matthieu.longo@arm.com \
--cc=schwab@suse.de \
--cc=srinath.parvathaneni@arm.com \
--cc=thiago.bauermann@linaro.org \
/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