Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Matthieu Longo <matthieu.longo@arm.com>, 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: Mon, 17 Aug 2026 12:59:09 -0400	[thread overview]
Message-ID: <a410e0b4-fcdd-4888-b6c7-4852359c7c6b@simark.ca> (raw)
In-Reply-To: <1e524861-e8e5-42f5-ac40-66b017f15670@arm.com>

On 8/14/26 6:05 AM, Matthieu Longo wrote:
> 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 ?

I think I was a bit confused about how the siginfo convenience variable
is constructed.  I thought we had code to set the value of individual
fields, but that does not make sense.  How it actually works is that we
read the bytes from the target, and the type constructed by
linux_get_siginfo_type (not only Linux, but all platforms) must overlay
perfectly the actual byte layout from the target.

But in any case, I don't think that anything from nat/ is used during
that process normally.  The type of $_siginfo comes from a struct type
constructed with arch_composite_type & co calls, not from a literal
struct in the GDB source code.

> #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.  */
> };

This is a bit hard to read, but yeah I guess that having all the struct
and union fields anonymouns would make the si_* fields accessible from
the top-level, and that would be ideal from a UX point of view.  So, we
would like to model a structure like the above, but constructed with
arch_composite_type & co calls.

But we'd need the old names to keep working.

You don't have to worry about this though (unless you want to), it's out
of scope of your original patch.

Simon


  reply	other threads:[~2026-08-17 16:59 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
2026-08-17 16:59         ` Simon Marchi [this message]
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=a410e0b4-fcdd-4888-b6c7-4852359c7c6b@simark.ca \
    --to=simark@simark.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=luis.machado.foss@gmail.com \
    --cc=luis.machado@amd.com \
    --cc=macro@orcam.me.uk \
    --cc=matthieu.longo@arm.com \
    --cc=schwab@suse.de \
    --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