Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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

  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