From: Matthieu Longo <matthieu.longo@arm.com>
To: gdb-patches@sourceware.org
Cc: Luis Machado <luis.machado@amd.com>,
Luis Machado <luis.machado.foss@gmail.com>,
Thiago Jung Bauermann <thiago.bauermann@linaro.org>,
Srinath Parvathaneni <srinath.parvathaneni@arm.com>,
"Maciej W . Rozycki" <macro@orcam.me.uk>
Subject: Re: [PATCH v4] gdb: align siginfo_t with the Linux kernel definition
Date: Tue, 28 Jul 2026 11:44:09 +0100 [thread overview]
Message-ID: <49d81485-da89-4a36-91db-b135eee18258@arm.com> (raw)
In-Reply-To: <20260727140828.68323-1-matthieu.longo@arm.com>
On 27/07/2026 15:08, Matthieu Longo wrote:
> diff --git a/gdb/linux-tdep.h b/gdb/linux-tdep.h
> index c19839fde2c..1dd0b3d2a17 100644
> --- a/gdb/linux-tdep.h
> +++ b/gdb/linux-tdep.h
> @@ -98,4 +98,64 @@ 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);
>
> +namespace gdb {
> +
> +/* Maps each siginfo_type::key to the corresponding field-access expression
> + in $_siginfo.
> +
> + Keep the order of key values synchronized with the entries in get()'s
> + paths array. Each key is used directly as an array index. */
> +
> +struct siginfo_type
> +{
> + /* Identifies a field within siginfo_t that may be referenced by name. */
> + enum class key
> + {
> + si_signo = 0,
> + si_errno,
> + si_code,
> +
> + /* SIGILL, SIGFPE, SIGSEGV, SIGBUS, SIGTRAP, SIGEMT */
> + si_addr,
> + si_trapno,
> + si_addr_lsb,
> + si_lower,
> + si_upper,
> + si_pkey,
> + si_perf_data,
> + si_perf_type,
> + si_perf_flags,
> +
> + /* Sentinel used to determine the number of mapped fields. */
> + SI_ATTR_END
> + };
> +
Thanks to Linaro's CI, I found a build issue in this patch.
Some of the enum names (si_addr) conflicts with macros defined in <signal.h> depending on the
version of Glibc installed on the machine I guess.
I could not reproduce the issue on my normal dev machine.
After the fix, the build passes and the macro values don't seem to conflict anymore with the enum
values.
Please let me know if you find a better solution to fix this build issue.
Note: renaming the enum values is an option, but then create inconsistencies with the names of
macros which I would prefer to be aligned.
enum class key
{
si_signo = 0,
si_errno,
si_code,
/* It seems that depending on the GLibc version and GCC version, macros
in <signal.h> conflicts with some names in the enum. Hence all those
push_macro and pop_macro. Referencing those names later in the code
does not seem to trigger a build issue. */
#pragma push_macro("si_addr")
#undef si_addr
#pragma push_macro("si_addr_lsb")
#undef si_addr_lsb
#pragma push_macro("si_lower")
#undef si_lower
#pragma push_macro("si_upper")
#undef si_upper
#pragma push_macro("si_pkey")
#undef si_pkey
/* SIGILL, SIGFPE, SIGSEGV, SIGBUS, SIGTRAP, SIGEMT */
si_addr,
si_trapno,
si_addr_lsb,
si_lower,
si_upper,
si_pkey,
si_perf_data,
si_perf_type,
si_perf_flags,
si_tchange_target,
si_tchange_type,
si_tchange_flags,
#pragma pop_macro("si_addr")
#pragma pop_macro("si_addr_lsb")
#pragma pop_macro("si_lower")
#pragma pop_macro("si_upper")
#pragma pop_macro("si_pkey")
/* Sentinel used to determine the number of mapped fields. */
SI_ATTR_END
};
> + /* Return the $_siginfo access expression associated with ATTR_.
> +
> + ATTR_ must be a valid si_* key other than SI_ATTR_END. The array
> + order must exactly match the declaration order of the keys above. */
> + static constexpr const char *get (key attr_)
> + {
> + const char *paths[static_cast<size_t> (key::SI_ATTR_END)] = {
> + "$_siginfo.si_signo",
> + "$_siginfo.si_errno",
> + "$_siginfo.si_code",
> +
> + /* SIGILL, SIGFPE, SIGSEGV, SIGBUS, SIGTRAP, SIGEMT */
> + "$_siginfo._sifields._sigfault.si_addr",
> + "$_siginfo._sifields._sigfault._anon_union.si_trapno",
> + "$_siginfo._sifields._sigfault._anon_union.si_addr_lsb",
> + "$_siginfo._sifields._sigfault._anon_union._addr_bnd.si_lower",
> + "$_siginfo._sifields._sigfault._anon_union._addr_bnd.si_upper",
> + "$_siginfo._sifields._sigfault._anon_union._addr_pkey.si_pkey",
> + "$_siginfo._sifields._sigfault._anon_union._perf.si_perf_data",
> + "$_siginfo._sifields._sigfault._anon_union._perf.si_perf_type",
> + "$_siginfo._sifields._sigfault._anon_union._perf.si_perf_flags",
> + };
> + return paths[static_cast<size_t> (attr_)];
> + }
> +};
> +
> +} /* namespace gdb */
> +
> #endif /* GDB_LINUX_TDEP_H */
Matthieu
next prev parent reply other threads:[~2026-07-28 10:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 14:08 Matthieu Longo
2026-07-28 10:44 ` Matthieu Longo [this message]
2026-07-28 11:09 ` Andreas Schwab
2026-07-28 12:29 ` Matthieu Longo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49d81485-da89-4a36-91db-b135eee18258@arm.com \
--to=matthieu.longo@arm.com \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado.foss@gmail.com \
--cc=luis.machado@amd.com \
--cc=macro@orcam.me.uk \
--cc=srinath.parvathaneni@arm.com \
--cc=thiago.bauermann@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox