RE: [PATCH v4 3/4] gdb/infrun: handle stepping through functions with DW_AT_trampoline

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

>Well, it just seems strange to me that after this series we would have two different ways of handling trampolines, that depend on how the trampoline is represented by the compiler (something nearly no user will understand or care about), and that there will be two different ways to elide frames from a "bt" (there's another one for frame filters).

Will elide the frames in V5 series of patch for frame filters also by using similar way in function "frame_object_to_frame_info" used by python which will elide the trampoline frames.

>If we think users don't want to see trampoline frames by default, by all means elide them, but the setting ought to make sense from a user perspective, not from a compiler implementer perspective
So what's the best in your opinion, shall we just elide like other cases which we anyways do as default and only let the user to disable eliding if he wants by using this option.

Thanks & Best Regards
Abdul Basit

-----Original Message-----
From: Tom Tromey <tom@tromey.com> 
Sent: Thursday, August 10, 2023 6:56 PM
To: Ijaz, Abdul B via Gdb-patches <gdb-patches@sourceware.org>
Cc: Tom Tromey <tom@tromey.com>; Ijaz, Abdul B <abdul.b.ijaz@intel.com>; JiniSusan.George@amd.com; eliz@gnu.org; blarsen@redhat.com
Subject: Re: [PATCH v4 3/4] gdb/infrun: handle stepping through functions with DW_AT_trampoline

>> It also seems a bit weird that skip_trampoline_functions only affects 
>> this one subset of trampoline functions.

> So skip_trampoline_functions is so far only handling the skipping case 
> for trampolines indicated by DW_AT_trampoline and not for any other 
> case of these thunks emitted by compiler or by signal trampolines. 
> Since this case is pretty much defined case for subroutines calling 
> the target subroutine but not sure about others but may be these solib 
> calls filtering may also be handled with the same. Please let me know 
> if we want to filter other trampolines cases using the same filter. 
> Mostly it should be "on" case but DW_AT_trampoline could be 
> interesting for user if compiler emit it for virtual functions and 
> user want to see all the trampoline calls so here there could be some 
> cases for end user to see those trampoline calls but for thunks or 
> rest I don’t know so let me know then I can asses of using the filter 
> option for other trampolines.

Well, it just seems strange to me that after this series we would have two different ways of handling trampolines, that depend on how the trampoline is represented by the compiler (something nearly no user will understand or care about), and that there will be two different ways to elide frames from a "bt" (there's another one for frame filters).

If we think users don't want to see trampoline frames by default, by all means elide them, but the setting ought to make sense from a user perspective, not from a compiler implementer perspective.

Tom
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928