Re: [PATCH v11 10/10] gdb: Filter trampoline frames in backtrace when using Python frame-filters.

[Tom Tromey <tom@tromey.com>]

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

> In case of the Python frame-filters, this change filters trampoline functions
> when the option 'skip-trampoline-functions' is set to 'on'.  GDB recently
> added the option to hide frames that are marked by the compiler with
> "DW_AT_trampoline", see commit 'Skip trampoline frames for the backtrace
> command'.  This implements the same functionality when python frame filters
> are in use.

> diff --git a/gdb/python/py-frame.c b/gdb/python/py-frame.c
> index afa89f0d112..098b37230e1 100644
> --- a/gdb/python/py-frame.c
> +++ b/gdb/python/py-frame.c
> @@ -59,6 +59,17 @@ frame_object_to_frame_info (PyObject *obj)
>    if (frame == NULL)
>      return NULL;
 
> +  if (skip_trampoline_functions)
> +    {
> +      for (int i = 0; (SAFE_TRAMPOLINE_CHAIN (i, frame)
> +		       && in_trampoline_frame (frame)); ++i)
> +	{
> +	  frame = get_prev_frame (frame);
> +	  if (frame ==  nullptr)
> +	    return nullptr;
> +	}
> +    }

This seems suspicious to me.

For one thing, suppose you have A -> Trampoline -> B.  Then in Python
you fetch the frame B.  What does B.newer() return?

I think with this code it will just return B again.

For DAP, and frame filters, I tend to think it would be better for
Python to simply see the frames as they are, but then add a new
attribute -- on the frame, but also maybe on the symbol -- indicating if
it's been marked as a trampoline.

Then maybe _FrameDecoratorBase.elided could return True if the frame is
a non-"live" trampoline frame.

Tom