From: Matthieu Longo <matthieu.longo@arm.com>
To: Simon Marchi <simark@simark.ca>, 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>,
Andreas Schwab <schwab@suse.de>
Subject: Re: [PATCH v5] gdb: align siginfo_t with the Linux kernel definition
Date: Fri, 14 Aug 2026 11:05:38 +0100 [thread overview]
Message-ID: <1e524861-e8e5-42f5-ac40-66b017f15670@arm.com> (raw)
In-Reply-To: <64c7d358-b3b7-4f8b-8485-73c976203260@simark.ca>
On 13/08/2026 16:49, Simon Marchi wrote:
> On 8/13/26 10:48 AM, Matthieu Longo wrote:
>> diff --git a/gdb/gdbtypes.h b/gdb/gdbtypes.h
>> index dd2d24fa8e2..e4fedd886c4 100644
>> --- a/gdb/gdbtypes.h
>> +++ b/gdb/gdbtypes.h
>> @@ -2431,11 +2431,12 @@ extern struct type *init_pointer_type (type_allocator &alloc, int bit,
>> extern struct type *init_fixed_point_type (type_allocator &, int, int,
>> const char *);
>>
>> -/* Helper functions to construct a struct or record type. An
>> - initially empty type is created using arch_composite_type().
>> - Fields are then added using append_composite_type_field*(). A union
>> - type has its size set to the largest field. A struct type has each
>> - field packed against the previous. */
>> +/* Helper functions to construct a struct or record type. An initially empty
>> + type is created using arch_composite_type(). Fields are then added using
>> + append_composite_type_field*().
>> + A union type has its size set to the largest field. A struct type has each
>> + field packed against the previous.
>> + If no name is specified, the type is anonymous. */
>>
>> extern struct type *arch_composite_type (struct gdbarch *gdbarch,
>> const char *name, enum type_code code);
>
> It's not the name of the type that matters, it's the name of the field,
> when added with append_composite_type_field, that does. When a struct
> or union field has no name, it is anonymous, and its fields are visible
> directly in the parent scope.
>
> I mean, it's true that passing no name creates an anonymous type, but
> that's not what matters in the problem at hand. Also, it should be
> clearer: "no name" means empty string or nullptr?
>
I moved this to another patch since it is not directly related to this patch.
https://inbox.sourceware.org/gdb-patches/20260813172736.500755-1-matthieu.longo@arm.com/
>>> I think that the ideal user experience would be for users to be able to
>>> access fields the same way that they do in the code, that is
>>> `si.si_pkey`. All the _sigfault/_addr_pkey/etc parts are implementation
>>> details that could change.
>>>
>>> On top of your patch, if I just delete all the internal field names, it
>>> seems to work just fine, see patch below. In the end it models
>>> something like this in C:
>>>
>> I am not against it.
>> However, could this suggestion be addressed in a different patch ?
>
> As I said above, we can't just rename the existing fields, there is
> probably code out there relying on those names.
>
> We could add new fields, so the structure would just contain both the
> named hierarchy and the anonymous hierarchy, the fields would just be
> duplicated. That's fine if the structure is read-only, but if for some
> reason some user code needs to change a field (I don't really know why
> it would do that), then that would be awkward, since it would only
> update one copy.
>
> Anyway, that's for later (if ever).
>
>> Simplifying the existing pathes to si_* values with anonymous structs would increase the impact of
>> the original patch, with potentially additional testing and carefulness required for others
>> architectures (for example, see gdb/nat/amd64-linux-siginfo.c L269).
>
> Hmm, I don't think we need to touch this nat code. I am only talking
> about the type of the $_siginfo convenience variable, which we build
> manually with those arch_composite_type & co calls.
>
> Simon
So, if I understood you well, you don't want to touch the current definition in
linux_get_siginfo_type(). Instead, you propose to define a new siginfo type as the data structure
below. Then, siginfo data should be cast to the new user-facing type before being returned.
Is this correct ?
#define __ARCH_SI_CLOCK_T unsigned long
#define __ADDR_BND_PKEY_PAD (__alignof__(void *) < sizeof(short) ? \
sizeof(short) : __alignof__(void *))
struct siginfo {
int si_signo;
int si_errno;
int si_code;
/* Beginning of __sifields. */
union {
/* _kill, signals, _sigchld and _timer are tangled, so should be flattened
together. */
struct {
union {
int si_pid; // _kill, _rt, _sigchld
int si_tid; // _timer
};
union {
uint32_t si_uid; // _kill, _rt, _sigchld
int si_overrun; // _timer
};
union {
struct {
int si_status;
__ARCH_SI_CLOCK_T si_utime;
__ARCH_SI_CLOCK_T si_stime;
}; // _sigchld
struct {
union {
int si_int;
void *si_ptr;
} si_value; // _rt, _timer
int si_sys_private; // _timer
};
};
};
/* _sigfault, _sigpoll and _sigsys are not sharing anything, so are
flattened on their own. */
struct {
void *si_addr;
union {
int si_trapno;
short si_addr_lsb;
struct {
char _dummy_padding_1[__ADDR_BND_PKEY_PAD];
void *si_lower;
void *si_upper;
}; /* _addr_bnd */
struct {
char _dummy_padding_2[__ADDR_BND_PKEY_PAD];
uint32_t si_pkey;
}; /* _addr_pkey */
struct {
unsigned long si_perf_data;
uint32_t si_perf_type;
uint32_t si_perf_flags;
}; /* _perf */
};
}; /* _sigfault */
struct {
long si_band;
int si_fd;
}; /* _sigpoll */
struct {
void *si_call_addr;
int si_syscall;
unsigned int si_arch;
}; /* _sigsys */
}; /* End of __sifields. */
};
Matthieu
next prev parent reply other threads:[~2026-08-14 10:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 12:32 Matthieu Longo
2026-08-03 8:23 ` Matthieu Longo
2026-08-12 21:55 ` Luis
2026-08-12 19:08 ` Simon Marchi
2026-08-13 14:48 ` Matthieu Longo
2026-08-13 15:49 ` Simon Marchi
2026-08-14 10:05 ` Matthieu Longo [this message]
2026-08-17 16:59 ` Simon Marchi
2026-08-17 9:33 ` Matthieu Longo
2026-08-17 16:42 ` Simon Marchi
2026-08-17 21:37 ` 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=1e524861-e8e5-42f5-ac40-66b017f15670@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=schwab@suse.de \
--cc=simark@simark.ca \
--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