Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


      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