RE: [PATCH v11 04/10] gdb: Skip trampoline frames for the backtrace command.

["Ijaz, Abdul B" <abdul.b.ijaz@intel.com>]

Thanks Tom, for the feedback.

Please see the inline reply below:

Tom> It's maybe somewhat unfortunate that this doesn't follow the precedent set by Python frame filters, where a frame can be marked  "elided" and then is either printed indented (the default) or hidden (with "bt -hide").

Abdul> "bt -hide" is a backtrace option, but frames can currently only be marked as elided by a Python frame filter , and only the Python printing code in py-framefilter.c honors it; the built-in backtrace loop never elides frames.

Using elision for trampolines would be possible, but needs:

- the built-in backtrace (no filters, or "bt -no-filters") to attach a trampoline frame as elided to the frame it calls, print it indented, and drop it for "bt -hide";
- the same for the frames passed to Python frame filters, so that trampolines are elided and not printed as normal frames when a user filter is loaded;
- the MI -stack-list-* commands to report them as "children", like the Python frame filter code does for MI.

It would also change the default: trampolines would be shown, indented, unless "bt -hide" is used, while this series hides them by default because the compiler marks them with DW_AT_trampoline so that a debugger does not show them.  On the positive side it would solve the "live" frame issue below for free, since a trampoline at frame #0 has no inner frame to be elided under and would be printed normally.  Stepping, "up", "finish" and "return" are not affected either way.

Would you prefer that then I go with elision, or otherwise keep hiding trampoline frames by default, controlled by skip-trampoline-functions?

>> +      if (skip_trampoline_functions && in_trampoline_frame (fi))
>> +        {
>> +          /* Trampoline frames are not printed so they are not counted in
>> +             the backtrace limit.  */
>> +          count++;
>> +          continue;
>> +        }

Tom> What happens if I "break 0x..." using an address in a trampoline function and then "bt" from there?
Tom>  I think this means the frame won't be printed.  But this could be confusing because gdb will be lying about the PC.
Tom> In this scenario what would "disassemble" by itself show?
Tom> That is, I somewhat suspect that there should be a special case here for the "live" frame.

Abdul > You are right: with the default "skip-trampoline-functions on", frame #0 is not printed, while "frame", "info frame" and "disassemble" all show the trampoline, so the backtrace does not match the PC. Only with "set skip-trampoline-functions off" does "bt" show it. For example, with the gdb.dwarf2/dw2-function-trampolines.exp program:

'''
(gdb) info address trampoline_label
Symbol "trampoline_label" is at 0x55555555514f in a file compiled without debugging.
(gdb) info address trampoline_label
Symbol "trampoline_label" is at 0x55555555514f in a file compiled without debugging.
(gdb) break *0x55555555514f
Breakpoint 2 at 0x55555555514f
(gdb) continue
Continuing.

Breakpoint 2, 0x000055555555514f in trampoline ()
(gdb) bt
#1  0x00005555555551ec in main () at gdb.dwarf2/dw2-function-trampolines.c:73
(gdb) x/i $pc
=> 0x55555555514f <trampoline+8>:       mov    0x2ebf(%rip),%eax        # 0x555555558014 <global_var>
(gdb) set skip-trampoline-functions off
(gdb) bt
#0  0x000055555555514f in trampoline ()
#1  0x00005555555551ec in main () at gdb.dwarf2/dw2-function-trampolines.c:73
'''
If we keep hiding trampoline frames instead of eliding them, for v12 I will always print the innermost frame to fix it, even if it is a trampoline, and only hide the trampoline frames further out (with elision this happens anyway).  Either way I will add a test that stops at a trampoline address with "break *ADDR" and checks that "bt" shows the trampoline as frame #0. So this special case will be handled.

Best Regards,
Abdul Basit


-----Original Message-----
From: Tom Tromey <tom@tromey.com> 
Sent: Wednesday, October 21, 2026 10:51 PM
To: Ijaz, Abdul B <abdul.b.ijaz@intel.com>
Cc: gdb-patches@sourceware.org; JiniSusan.George@amd.com; tom@tromey.com; eliz@gnu.org
Subject: Re: [PATCH v11 04/10] gdb: Skip trampoline frames for the backtrace command.

>>>>> Abdul Basit Ijaz <abdul.b.ijaz@intel.com> writes:

> This change filters trampoline functions when the option 
> 'skip-trampoline-functions' is set to 'on' for the backtrace command.
> Before the change, GDB prints the frames indicated by the compiler 
> with DIE "DW_AT_trampoline" in the backtrace, but for better user 
> experience, all such frames can be hidden from the user.

> For O2 optimized code where inlined trampoline wrappers are inlined 
> into regular functions.  Check the frame's function directly for 
> inline frames instead of looking up by PC, which would incorrectly 
> return the caller's function.

> The test 'gdb.fortran/mixed-lang-stack' test used to fail for the IFX 
> compiler because of extra trampoline frames in the backtrace.  After 
> the commit, those trampoline frames are filtered and test is updated accordingly.

It's maybe somewhat unfortunate that this doesn't follow the precedent set by Python frame filters, where a frame can be marked "elided" and then is either printed indented (the default) or hidden (with "bt -hide").

> diff --git a/gdb/stack.c b/gdb/stack.c index f41f818cebb..fa217ae9f6f 
> 100644
> --- a/gdb/stack.c
> +++ b/gdb/stack.c
> @@ -1978,6 +1978,14 @@ backtrace_command_1 (const frame_print_options &fp_opts,
>  	{
>  	  QUIT;
 
> +	  if (skip_trampoline_functions && in_trampoline_frame (fi))
> +	    {
> +	      /* Trampoline frames are not printed so they are not counted in
> +		 the backtrace limit.  */
> +	      count++;
> +	      continue;
> +	    }

What happens if I "break 0x..." using an address in a trampoline function and then "bt" from there?

I think this means the frame won't be printed.  But this could be confusing because gdb will be lying about the PC.

In this scenario what would "disassemble" by itself show?

That is, I somewhat suspect that there should be a special case here for the "live" frame.

Tom
________________________________________
Intel Deutschland GmbH 

Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany 

Tel: +49 (89) 99143-0 

www.intel.de 

Managing Directors: Candice Moore, Jeffrey Schneiderman, Ramachandran Sitaraman

Chairperson of the Supervisory Board: Sonja Pierer

Registered Seat: Munich Commercial Register B: Amtsgericht Munich HRB 186928

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.