> -----Original Message----- > From: Thiago Jung Bauermann > Sent: Monday, October 13, 2025 3:17 AM > To: Schimpe, Christina > Cc: Eli Zaretskii ; gdb-patches@sourceware.org > Subject: Re: [PATCH 6/9] gdb: Implement 'bt shadow' to print the shadow > stack backtrace. > > Hello, > > "Schimpe, Christina" writes: > > >> -----Original Message----- > >> From: Eli Zaretskii > >> Sent: Tuesday, September 23, 2025 1:47 PM > >> To: Schimpe, Christina > >> Cc: gdb-patches@sourceware.org > >> Subject: Re: [PATCH 6/9] gdb: Implement 'bt shadow' to print the > >> shadow stack backtrace. > >> > >> > From: Christina Schimpe > >> > Date: Tue, 23 Sep 2025 11:18:39 +0000 > >> > > >> > Add a subcommand 'bt shadow' for the ordinary backtrace command > >> > which prints the shadow stack backtrace. > >> > Similar to the ordinary backtrace command 'bt shadow' can be > >> > configured using COUNT and the command line option -frame-info. > >> > However, we always print the address and the command is not > >> > affected by the setting "print address" as well as the setting > >> > "print frame-info > >> location-and-address". > >> > Also we do not print the frame arguments. > >> > > >> > Usage: backtrace|bt shadow [OPTION]... [COUNT | -COUNT] > >> > > >> > Help output: > >> > ~~ > >> > (gdb) help bt shadow > >> > Print backtrace of all shadow stack frames, or innermost COUNT frames. > >> > Usage: backtrace shadow [OPTION]... [COUNT | -COUNT] > >> > >> 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. > > > > Currently, we don't plan any further commands for the shadow stack. > > But maybe for ARM's Guarded Control Stack any further options are > planned? > > I added Thiago in cc here. Maybe he has some more input. > > Yes, I plan to add two commands for AArch64 Guarded Control Stack, as > mentioned in that thread: > > https://inbox.sourceware.org/gdb/87h6kbfazh.fsf@linaro.org/ > > In that email, I suggested putting them under "info shadow-stack", but later > the people in the thread considered that just adding a top-level "shadow- > stack" command would be better. > > I do think that "backtrace -shadow" is a good option, so IMO we could have > both it and the "shadow-stack" umbrella command. It could even have > "shadow-stack backtrace" as an alias to "backtrace -shadow" to improve > discoverability. I have nothing against that I think, are there similar commands in GDB that have such an alias feature? > You mentioned that x86 doesn't need the "enabled" and "locked" commands > because for that architecture the user can look in /proc/$PID/status, but with > those commands I also plan to allow the user to change the enabled and > locked GCS features. Wouldn't that be useful for x86? For x86 the user can configure the shadow stack enabled and locked state via arch_prctls: https://docs.kernel.org/next/x86/shstk.html Is that possible for GCS, too? I am not sure if we can easily change it using GDB. We currently only read/write the shadow stack pointer via ptrace. But it is possible to see those states by running "info proc status" in gdb: [...] x86_Thread_features: shstk x86_Thread_features_locked: shstk wrss So I'd say we don't really need it, but it might be useful to improve discoverability, too. I think a similar topic is the GDB GCS feature to find out the reason for a segmentation fault: ~~~ Program received signal SIGSEGV, Segmentation fault Guarded Control Stack error. ~~~ In theory, the user can use the si code by examining siginfo, but having the additional line as for GCS improves discoverability. So for now we decided to keep it simple, and hope that the user will get along with the existing interfaces. If there is the common opinion to add the commands (read-only) and an additional line for SEGVs due to a shadow-stack/cet violation in case of x86, I think we can add it, too. Regards, Christina