Re: [PATCH v3] gdb: align siginfo_t with the Linux kernel definition
Matthieu Longo <[email protected]> Fri, 24 Jul 2026 10:42:09 +0100
| Newsgroups | gmane.comp.gdb.patches |
|---|---|
| Message-ID | <[email protected]> |
On 24/07/2026 10:18, Matthieu Longo wrote: Sorry, the previous email left by mistake. > On 23/07/2026 00:09, Luis wrote: >> Hi Matthieu, >> >> On 22/07/2026 16:00, Matthieu Longo wrote: >>> On 21/07/2026 22:09, Luis wrote: >>>> On 02/07/2026 17:52, Matthieu Longo wrote: >>> --- a/gdb/linux-tdep.c >>> +++ b/gdb/linux-tdep.c >>>>> + append_composite_type_field (sigfault_union_type, "si_addr_lsb", short_type); >>>>> + >>>>> + /* used when si_code=SEGV_BNDERR */ >>>>> + type = arch_composite_type (gdbarch, NULL, TYPE_CODE_STRUCT); >>>>> + append_composite_type_field (type, "_dummy_bnd", addr_bnd_pkey_padding_type); >>>>> + append_composite_type_field (type, "si_lower", void_ptr_type); >>>>> + append_composite_type_field (type, "si_upper", void_ptr_type); >>>>> + append_composite_type_field (sigfault_union_type, "_addr_bnd", type); >>>>> + >>>>> + /* used when si_code=SEGV_PKUERR */ >>>>> + type = arch_composite_type (gdbarch, NULL, TYPE_CODE_STRUCT); >>>>> + append_composite_type_field (type, "_dummy_pkey", addr_bnd_pkey_padding_type); >>>>> + append_composite_type_field (type, "si_pkey", uint32_type); >>>>> + append_composite_type_field (sigfault_union_type, "_addr_pkey", type); >>>>> + >>>>> + /* used when si_code=TRAP_PERF */ >>>>> + type = arch_composite_type (gdbarch, NULL, TYPE_CODE_STRUCT); >>>>> + append_composite_type_field (type, "si_perf_data", unsigned_long_type); >>>>> + append_composite_type_field (type, "si_perf_type", uint32_type); >>>>> + append_composite_type_field (type, "si_perf_flags", uint32_type); >>>>> + append_composite_type_field (sigfault_union_type, "_perf", type); >>>>> + >>>>> + /* End _sigfault's anonymous union. */ >>>>> + >>>>> + /* _sigfault is set by SIGILL, SIGFPE, SIGSEGV, SIGBUS, SIGTRAP, SIGEMT */ >>>>> type = arch_composite_type (gdbarch, NULL, TYPE_CODE_STRUCT); >>>>> append_composite_type_field (type, "si_addr", void_ptr_type); >>>>> + /* Since there is no possibility to declare an anonymous union, >>>>> + using '_' instead. */ >>>>> + append_composite_type_field (type, "_", sigfault_union_type); >>>> >>>> Could we name this in a better way? Simply using _ is a bit strange. >>>> >>> >>> What about "_union" ? >>> >> >> Naming is hard. Given it is an anonymous union, should it have something anonymous in the name? >> > > I understand your point, but the name is going to start getting very lengthy. > What about "_anon_union" ? > >> If we're going to access this by hand, it might be worth having some easy to use too. >> > > What type of accessors do you have in mind ? Compile-time ones ? Or runtime ones at the destination > of the GDB users when accessing _siginfo ? > > For the compile-time ones, I propose to add those defines: > --- a/gdb/linux-tdep.h > +++ b/gdb/linux-tdep.h > @@ -98,4 +98,18 @@ extern CORE_ADDR linux_get_hwcap2 (); > extern bool linux_address_in_shadow_stack_mem_range > (CORE_ADDR addr, std::pair<CORE_ADDR, CORE_ADDR> *range); > > +/* How the fields from siginfo_t's _sigfault can be accessed. */ > +#ifdef si_addr > +#error "Matthieu: this should not happen" > +#endif > +#define si_addr "_sifields._sigfault.si_addr" > +#define si_trapno "_sifields._sigfault._anon_union.si_trapno" > +#define si_addr_lsb "_sifields._sigfault._anon_union.si_addr_lsb" > +#define si_lower "_sifields._sigfault._anon_union._addr_bnd.si_lower" > +#define si_upper "_sifields._sigfault._anon_union._addr_bnd.si_upper" > +#define si_pkey "_sifields._sigfault._anon_union._addr_pkey.si_pkey" > +#define si_perf_data "_sifields._sigfault._anon_union._perf.si_perf_data" > +#define si_perf_type "_sifields._sigfault._anon_union._perf.si_perf_type" > +#define si_perf_flags "_sifields._sigfault._anon_union._perf.si_perf_flags" > + This solution for accessors does not work because the si_* defines conflict with the ones from /usr/include/aarch64-linux-gnu/bits/types/siginfo_t.h I will come back to you with another approach that does not conflict with the linux kernel headers (potentially with <signal.h> too). Matthieu