Re: [PATCH v5] gdb: align siginfo_t with the Linux kernel definition
Luis <[email protected]>
| Newsgroups | gmane.comp.gdb.patches |
|---|---|
| Message-ID | <[email protected]> |
On 03/08/2026 09:23, Matthieu Longo wrote: > On 28/07/2026 13:32, 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. >> >> 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. >> >> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ >> tree/include/uapi/asm-generic/siginfo.h#n69 >> [2]: https://lore.kernel.org/all/[email protected]/ >> >> Reviewed-by: Thiago Jung Bauermann <[email protected]> > Ping. > > @Luis: I addressed your suggestion for compile time accessors. I think that it is cleaner than a > hard-coded string anyway. Please let me know what you if you are happy with the current state. Thanks. It looks cleaner indeed. The aarch64 parts look OK to me, as does the test. I see Simon has made comments on the anonymous struct access. > > Regarding the GDB users' accessors, I haven't implemented them because the scope of this patch would > increase too much. Please see my response in v3 [1]. That's fine by me. > > [1]: https://inbox.sourceware.org/gdb-patches/[email protected]/ > > Matthieu