RE: [PATCH 6/9] gdb: Implement 'bt shadow' to print the shadow stack backtrace.

["Schimpe, Christina" <christina.schimpe@intel.com>]

Hi Simon,

Thank you for the feedback. 

> -----Original Message-----
> From: Simon Marchi <simark@simark.ca>
> Sent: Thursday, September 25, 2025 4:59 PM
> To: Eli Zaretskii <eliz@gnu.org>; Schimpe, Christina
> <christina.schimpe@intel.com>
> Cc: gdb-patches@sourceware.org; thiago.bauermann@linaro.org
> Subject: Re: [PATCH 6/9] gdb: Implement 'bt shadow' to print the shadow
> stack backtrace.
> 
> On 9/25/25 9:19 AM, Eli Zaretskii wrote:
> >> From: "Schimpe, Christina" <christina.schimpe@intel.com>
> >> CC: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
> >> "Thiago Jung  Bauermann" <thiago.bauermann@linaro.org>
> >> Date: Thu, 25 Sep 2025 11:06:32 +0000
> >>
> >>>> (gdb) help bt shadow
> >>>> Print backtrace of all shadow stack frames, or innermost COUNT frames.
> >>>> Usage: backtrace shadow [OPTION]... [COUNT | -COUNT]
> >>>
> >>> Thanks, but I wonder if this UI is the best we can come up with.
> >>> The "backtrace" command doesn't currently have non-option arguments
> >>> except COUNT.
> >>
> >> Hm, not sure if I fully understand what you mean by non-option
> arguments.
> >> "bt shadow" does not introduce more non-option arguments, except if
> >> you say that "shadow" itself is interpreted as "non-option" argument.
> >
> > That's what I'm saying, yes.
> >
> >>> We have just got rid of qualifier arguments like "full"
> >>> and "hide".  Instead of introducing qualifier arguments anew, why
> >>> not go the way of thread-related commands and add a new command
> >>> "shadow", so the user could say "shadow backtrace" and maybe in the
> >>> future also other sub- commands?
> >>
> >> This has been discussed in a thread years ago:
> >> https://sourceware.org/pipermail/gdb/2023-December/051024.html
> >> The direction was to make it part of the ordinary bt command.
> >
> > OK, if that's what the others want...
> 
> My initial reaction was: why not use a "-shadow" option to the backtrace
> command, instead of introducing "backtrace shadow", which is effectively a
> separate command?  I then re-read the thread above, and I saw that "-
> shadow" was actually part of the options considered, and even seemed like
> the preferred option of many.  I didn't see "backtrace shadow"
> proposed there, so I'm confused.

That's true. It has never been discussed.  When discussing this in the thread I
didn't have the option of subcommands in mind. 

> The thing I don't like about "backtrace shadow" is: I don't like when a
> command ("backtrace") is both a prefix and a regular command.  It can paint
> us in a corner at some point.  Let's say we want to introduce the
> syntax:
> 
>   (gdb) backtrace SYMBOL
> 
> at some point, then the sub-command "shadow" would conflict if someone
> wanted to call the command "backtrace" with the symbol "shadow".

Good point, I did not think about that.

> From what I read in the thread above, the downside of the "backtrace -
> shadow" option is that some other options wouldn't make sense for the
> shadow backtrace.  I don't think it's a problem, those other options can just be
> ignored when printing the shadow stack.

Yeah, this was one reason for me to not use "bt -shadow".
Another reason was that the current options of the ordinary backtrace command only
change the output format/range. The output of "bt shadow" looks similar in the first
place, but is created completely different so I also wanted to make a difference by
choosing the subcommand.

When moving to the implementation phase,  I decided to simply try it without reopening
the discussion in the gdb archives again. 
But if the common opinion here is to use "bt -shadow" I have no problem in changing that.
It should be straight forward to implement.

Christina
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928