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

[Matthieu Longo <matthieu.longo@arm.com>]

On 17/06/2026 07:07, Thiago Jung Bauermann wrote:
> 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.
> 

I imagined that compat_siginfo_t was also used in the case when the inferior is an AArch64 process, 
while GDB is AArch32.
Hence ...

>> 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?
> 

my surprise when I say the definition of _sigfault._addr as a uint32_t. This would not have worked 
in my understanding.

Matthieu