Fwd: Re: [RFA v2 00/13] various frame filter fixes and cleanups

[Phil Muldoon <pmuldoon at redhat dot com>]

Forwarding to list for completeness due to the Sourceware data loss.

-------- Forwarded Message --------
Subject: Re: [RFA v2 00/13] various frame filter fixes and cleanups
Date: Tue, 15 Aug 2017 13:25:15 +0100
From: Phil Muldoon <pmuldoon@redhat.com>
To: Tom Tromey <tom@tromey.com>
CC: Pedro Alves <palves@redhat.com>, gdb-patches@sourceware.org

On 14/08/17 23:05, Tom Tromey wrote:
>>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:
> 
> Phil> I'd prefer a "hidden" attribute to the frame decorators (or a callback
> Phil> API like the rest of the functions). Returns True or False. GDB would
> Phil> honour this and print/not print the frame according to the value
> Phil> returned. This is better, to me, than a global override printing/not
> Phil> printing all elided frames. The bt command should still have a global
> Phil> override (IE, elide, or hidden, or show-hidden, or whatever) as
> Phil> discussed in the patch, and that would allow the user final and manual
> Phil> control of what is printed or not. I prefer frame decorators to be
> Phil> able to decide what should, or should not, be printed as the default
> Phil> as it's the presentation layer.
> 
> Phil> What do you think?
> 
> First, I'm sorry I didn't respond about this the first time.  Seeing
> this note reminded me that you asked about this before.

That's ok because I totally forgot I mentioned it until you reminded
me ;)

> My view has been that this flag is just the existing "elided" field --
> it's just that we never implemented the part where we allow the elided
> frames to be hidden.
> 
> The use case I picture for elided frames is just that: hiding some
> frames from the user.  A typical case would be something like an
> interpreter, where multiple C frames make up a single call into the
> interpreter.  In this case the frame filter would replace all these
> 'implementation' frames with a single conceptual interpreter frame.
> 
> I am open to adding another mechanism here -- but what is the use case?

I've been looking at adding synthetic frames. It can be done right now
by borrowing a frame's architecture. But it is clumsy. More on this later.

I think that Frame Decorators should be in control of all aspects of
frame presentation and visibility. My proposal, in the last email, was
to implement a visibility flag in the default FrameDecorator object
and allow the inheriting frame decorator to override that visibility
flag. If the visibility flag is false, GDB won't print the frame (and
in the base FrameDecorator object the flag defaults to true, so it has
to be explicitly set or overridden to be set to false). This applies
to all frames, whether elided or not.

This allows Frame Filters and Frame Decorators to make decisions on
the total scope of how a backtrace looks and these decisions are made
entirely by the author of the decorator/filter. It also allows you to
hide some frames (elided, or not) and not others, if the case requires
it. Having a global on/off to show/hide all elided frames seems a
little bit ungainly to me when the frame decorators/filters could make
that decision on a frame by frame basis. You can do this now, in a
limited fashion, by having the frame filter chop/truncate the iterator
of Frame Decorators to exclude frames from the backtrace. But, back to
my point in the first paragraph, this again seems ungainly when a
simple attribute in each Frame Decorator could control frame
visibility in a more intuitive manner. I'm working on adding synthetic
frames to make it less ugly (IE, not need a frame), but I thought, on
the other side of the coin, there was an opportunity here to look at
frame visibility from a broader perspective than "hide just elided"
and having that option set by a switch.

But on that note, it's a suggestion, not an objection to the current
patch. I also acknowledge that my proposal is somewhat orthogonal to
the original functionality proposed in this patch.

Cheers

Phil