Re: [PATCH v1] gdb: align siginfo_t with the Linux kernel definition

[Thiago Jung Bauermann <thiago.bauermann@linaro.org>]

Hello Matthieu,

Matthieu Longo <matthieu.longo@arm.com> writes:

> On 12/06/2026 11:16, Matthieu Longo wrote:
>> 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.
>> [1]: https://github.com/torvalds/linux/blob/2b414a95b8f7307d42173ba9e580d6
>>       d3e2bcbfce/include/uapi/asm-generic/siginfo.h#L69-L100
>> [2]: https://lore.kernel.org/all/20160212210213.ABC488FA@viggo.jf.intel.com/
>> ---
>>   gdb/linux-tdep.c | 39 +++++++++++++++++++++++++++++++++++++--
>>   1 file changed, 37 insertions(+), 2 deletions(-)
>> 
> I was not sure who I should include for the review. Please feel free to CC the right
> persons if they are not already in the list.
>
> I tested the patch above, and it seems to work fine without any change in ./gdb/nat
> However, in my understanding, compat_siginfo_t should also be impacted. Why is it still
> working then without any change ?

    ⋮

> aarch64_siginfo_from_compat_siginfo (in gdb/nat/aarch64-linux.c) and its friends for each
> backend seem to provide some conversion logic between the siginfo_t from the system
> (/usr/include/asm-generic/siginfo.h) and some internal representation compat_siginfo_t.
> From my research, this seems needed because, if the host and target systems are not using
> the same ABI (endianness, size of a pointer or int, etc...), GDB cannot rely on the local
> definition of siginfo_t to interpret correctly the data in the blob that it received from
> the target.

compat_siginfo_t is used when the inferior is an AArch32 process while
GDB is AArch64. This will cause the 64-bit kernel to use the syscall
compatibility layer — and thus the 32-bit definition of siginfo_t —
which GDB's compat_siginfo_t aims to represent.

> However, I am confused by the definition of compat_siginfo_t in gdb/nat/aarch64-linux.h
> for instance. I see that addresses like _sigfaul._addr are converted to 'unsigned int'
> (that should be equivalent to uint32_t I guess). Why is this working ?
>
> Please, could you provide explanations on the above, and guidances on the changes required
> in struct compat_siginfo_t ?

I'm not sure I understand why it wouldn't work. In the example of
_sigfault._addr, it is an unsigned int (equivalent to uint32_t as you
point out) so it will match the width of the void * used for the
corresponding void * field in 32-bit userspace. This is converted to
siginfo_t's 64-bit void * in aarch64_siginfo_from_compat_siginfo with:

  to->si_addr = (void *) (intptr_t) from->cpt_si_addr;

Do you see a problem in this process?

-- 
Thiago
(he/him)