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

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

On 18/06/2026 04:02, Thiago Jung Bauermann wrote:
> Matthieu Longo <matthieu.longo@arm.com> writes:
> 
>> 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 ...
> 
> Ah, ok. This isn't supported, at least in the Arm port. I think GDB in
> general doesn't support 32-bit GDB debugging 64-bit inferior, but I
> could be wrong. It's certainly not well tested though. :)
> 
>>>> 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.
> 
> Yes, indeed in that case it wouldn't work.
> 

If the feature that requires new fields in siginfo_t, is only available AArch64 only, there should 
not be any reason to change aarch64_siginfo_from_compat_siginfo and 
aarch64_compat_siginfo_from_siginfo. Is this correct ?

If so, then the current patch is complete and ready to be reviewed.