Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Schimpe, Christina" <christina.schimpe@intel.com>
To: Tom Tromey <tom@tromey.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	"thiago.bauermann@linaro.org" <thiago.bauermann@linaro.org>
Subject: RE: [PATCH v2 1/9] gdb: Generalize handling of the shadow stack pointer.
Date: Wed, 15 Apr 2026 07:35:34 +0000	[thread overview]
Message-ID: <SN7PR11MB7638CC419110485C7C0BFDF2F9222@SN7PR11MB7638.namprd11.prod.outlook.com> (raw)
In-Reply-To: <87se8xv436.fsf@tromey.com>

> -----Original Message-----
> From: Tom Tromey <tom@tromey.com>
> Sent: Dienstag, 14. April 2026 19:34
> To: Schimpe, Christina <christina.schimpe@intel.com>
> Cc: Tom Tromey <tom@tromey.com>; gdb-patches@sourceware.org;
> thiago.bauermann@linaro.org
> Subject: Re: [PATCH v2 1/9] gdb: Generalize handling of the shadow stack
> pointer.
> 
> >>>>> Schimpe, Christina <christina.schimpe@intel.com> writes:
> 
> > Sorry for getting back delayed response. I am seeing the following
> > when running check-gdbarch.py:
> 
> > ~~~
> > $ ./check-gdbarch.py
> > never set: shadow_stack_element_size_aligned ~~~
> 
> > Given that I assign a pre-default I don't have to configure it for amd64
> specifically.
> > But starting with this patch, this message will always appear when running
> the script.
> 
> > Should we change the script for this case?
> 
> It depends.
> 
> This means that no architecture sets this gdbarch parameter.
> So:
> 
> 1. Maybe it's not needed at all and should be removed, or 2. Maybe it's used
> in some later patch and the warning should be
>    ignored, or
> 3. Maybe it might be used in the future and we don't want to
>    hard-code the value and so it should be marked 'unused'
>    in gdbarch_components.py

It is currently not used in any subsequent patch. GCS, amd64, and x32 all use an 8‑byte offset.
In theory, Linux kernel support for 32‑bit shadow stacks could be added in the future, which
would require a 4‑byte offset. For other architectures, I don't know about the details.

So based on that I'd go with option 3, do you agree ?

I could add a comment such as:

+    # Currently unused but we wanted to keep this hook around,
+    # since x86 32-bit shadow stacks would require a 4-byte offset,
+    # for instance.  But this is not supported yet by the Linux kernel
+    # as x86 shadow stack for user space is only supported for amd64
+    # Linux starting with Linux kernel v6.6.
+    unused=True,

Alternatively, I could re-use the already existing shorter comment if you prefer:

+    # Currently unused but we wanted to keep this hook around.
+    unused=True,

I'd prefer the first comment, but keeping it short would be fine with me, too. 

Thanks,
Christina
Intel Deutschland GmbH
Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany
Tel: +49 89 991 430, www.intel.de
Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell
Chairperson of the Supervisory Board: Nicole Lau
Registered Seat: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

  reply	other threads:[~2026-04-15  7:36 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-23  8:05 [PATCH v2 0/9] Add new command to print the shadow stack backtrace Christina Schimpe
2026-01-23  8:05 ` [PATCH v2 1/9] gdb: Generalize handling of the shadow stack pointer Christina Schimpe
2026-02-19 17:55   ` Tom Tromey
2026-02-27 18:09     ` Schimpe, Christina
2026-02-27 18:26       ` Tom Tromey
2026-03-02 11:53         ` Schimpe, Christina
2026-04-09  9:49           ` Schimpe, Christina
2026-04-14 17:34             ` Tom Tromey
2026-04-15  7:35               ` Schimpe, Christina [this message]
2026-04-15 15:54                 ` Tom Tromey
2026-02-27 22:54       ` Thiago Jung Bauermann
2026-03-06  3:15   ` Thiago Jung Bauermann
2026-03-06  3:57     ` Thiago Jung Bauermann
2026-04-09 11:57       ` Schimpe, Christina
2026-04-10  5:03         ` Thiago Jung Bauermann
2026-04-10  7:53           ` Schimpe, Christina
2026-04-09 12:06   ` Schimpe, Christina
2026-04-10  5:05     ` Thiago Jung Bauermann
2026-01-23  8:05 ` [PATCH v2 2/9] gdb: Refactor 'stack.c:print_frame' Christina Schimpe
2026-01-23  8:05 ` [PATCH v2 3/9] gdb: Introduce 'stack.c:print_pc' function without frame argument Christina Schimpe
2026-01-23  8:05 ` [PATCH v2 4/9] gdb: Refactor 'find_symbol_funname' and 'info_frame_command_core' in stack.c Christina Schimpe
2026-02-19 17:32   ` Tom Tromey
2026-04-09 12:40     ` Schimpe, Christina
2026-01-23  8:05 ` [PATCH v2 5/9] gdb: Refactor 'stack.c:print_frame_info' Christina Schimpe
2026-01-23  8:05 ` [PATCH v2 6/9] gdb: Add command option 'bt -shadow' to print the shadow stack backtrace Christina Schimpe
2026-01-23  8:52   ` Eli Zaretskii
2026-02-13 16:42     ` Schimpe, Christina
2026-04-14  8:43       ` Schimpe, Christina
2026-04-14 11:53         ` Eli Zaretskii
2026-04-14 13:28           ` Schimpe, Christina
2026-04-14 14:12             ` Eli Zaretskii
2026-04-14 15:05               ` Schimpe, Christina
2026-02-19 18:19   ` Tom Tromey
2026-04-09 16:48     ` Schimpe, Christina
2026-03-06  4:31   ` Thiago Jung Bauermann
2026-03-06  9:39     ` Schimpe, Christina
2026-04-09 15:12     ` Schimpe, Christina
2026-04-10  6:21       ` Thiago Jung Bauermann
2026-04-10 12:12         ` Schimpe, Christina
2026-01-23  8:05 ` [PATCH v2 7/9] gdb: Provide gdbarch hook to distinguish shadow stack backtrace elements Christina Schimpe
2026-01-23  8:47   ` Eli Zaretskii
2026-02-19 17:41   ` Tom Tromey
2026-01-23  8:05 ` [PATCH v2 8/9] gdb: Implement the hook 'is_no_return_shadow_stack_address' for amd64 linux Christina Schimpe
2026-02-19 17:43   ` Tom Tromey
2026-01-23  8:05 ` [PATCH v2 9/9] gdb, mi: Add -shadow-stack-list-frames command Christina Schimpe
2026-01-23  8:46   ` Eli Zaretskii
2026-02-13 19:17     ` Schimpe, Christina
2026-02-19 18:26   ` Tom Tromey
2026-03-02 12:39 ` [PATCH v2 0/9] Add new command to print the shadow stack backtrace Schimpe, Christina

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=SN7PR11MB7638CC419110485C7C0BFDF2F9222@SN7PR11MB7638.namprd11.prod.outlook.com \
    --to=christina.schimpe@intel.com \
    --cc=gdb-patches@sourceware.org \
    --cc=thiago.bauermann@linaro.org \
    --cc=tom@tromey.com \
    /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