From: Phil Muldoon <pmuldoon@redhat.com>
To: Pedro Alves <palves@redhat.com>, Tom Tromey <tom@tromey.com>,
gdb-patches@sourceware.org
Subject: Re: [RFA v2 00/13] various frame filter fixes and cleanups
Date: Mon, 14 Aug 2017 13:57:00 -0000 [thread overview]
Message-ID: <b88f34a2-f185-852a-515a-d0ed34b766e8@redhat.com> (raw)
In-Reply-To: <a350981b-0bed-f1e3-1a98-ae3266d0b579@redhat.com>
On 14/08/17 14:20, Pedro Alves wrote:
> On 08/14/2017 04:40 AM, Tom Tromey wrote:
>
>>> So "bt elide" means "elide the elided frames", not "show me the
>>> elided frames too". It's fine with me, though I mildly wonder whether
>>> users will be confused by the "double negative".
>>
>> "Elide" means "drop", so really "bt elide" should mean "drop whatever
>> frames are droppable". Having "bt elide" mean "show the dropped
>> frames" would be confusing. But maybe another word would be better
>> here, I don't know.
>
> Maybe "bt no-elided", to go with "bt no-filters".
>
> Because "elided frames" are a preexisting concept, and "elide" is
> actually referring to that concept.
I suggest hidden or show-hidden or something like that.
>
> @item backtrace no-elided
> A Python frame filter might decide to ``elide'' some frames. Normally
> such elided frames are still printed, but they are indented relative
> to the filtered frames that cause them to be elided. The @code{no-elided}
> option causes elided frames to not be printed at all.
>
> Or alternatively, to make gdb not print elided frames by default and
> add a "bt elided" switch to print them:
>
> @item backtrace elided
> A Python frame filter might decide to ``elide'' some frames. Normally
> such elided frames are not printed. The @code{elided} option causes
> elided frames to be printed, indented relative to the filtered frames
> that cause them to be elided.
I'd prefer a "hidden" attribute to the frame decorators (or a callback
API like the rest of the functions). Returns True or False. GDB would
honour this and print/not print the frame according to the value
returned. This is better, to me, than a global override printing/not
printing all elided frames. The bt command should still have a global
override (IE, elide, or hidden, or show-hidden, or whatever) as
discussed in the patch, and that would allow the user final and manual
control of what is printed or not. I prefer frame decorators to be
able to decide what should, or should not, be printed as the default
as it's the presentation layer.
What do you think?
Cheers
Phil
next prev parent reply other threads:[~2017-08-14 13:57 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-14 3:41 Tom Tromey
2017-08-14 3:41 ` [RFA v2 03/13] Allow elision of some filtered frames Tom Tromey
2017-08-14 15:10 ` Eli Zaretskii
2017-08-14 3:41 ` [RFA v2 04/13] Remove EXT_LANG_BT_COMPLETED Tom Tromey
2017-08-14 3:41 ` [RFA v2 05/13] Avoid manual resource management in py-framefilter.c Tom Tromey
2017-08-14 3:41 ` [RFA v2 10/13] Call wrap_hint in one more spot " Tom Tromey
2017-08-14 3:41 ` [RFA v2 12/13] Simplify exception handling " Tom Tromey
2017-08-14 13:36 ` Pedro Alves
2017-08-14 3:41 ` [RFA v2 08/13] Move some code later in backtrace_command_1 Tom Tromey
2017-08-14 3:41 ` [RFA v2 02/13] Change backtrace_command_1 calling to use flags Tom Tromey
2017-08-14 3:41 ` [RFA v2 07/13] Throw a "quit" on a KeyboardException in py-framefilter.c Tom Tromey
2017-08-14 3:41 ` [RFA v2 13/13] Remove verbose code from backtrace command Tom Tromey
2017-08-14 13:35 ` Pedro Alves
2017-08-14 3:41 ` [RFA v2 09/13] Return EXT_LANG_BT_ERROR in one more spot in py-framefilter.c Tom Tromey
2017-08-14 3:41 ` [RFA v2 11/13] Improve "backtrace" help text Tom Tromey
2017-08-14 13:35 ` Pedro Alves
2017-08-14 14:34 ` Tom Tromey
2017-08-14 14:36 ` Pedro Alves
2017-08-14 14:38 ` Tom Tromey
2017-08-14 3:41 ` [RFA v2 01/13] Rationalize "backtrace" command line parsing Tom Tromey
2017-08-14 15:07 ` Eli Zaretskii
2017-08-14 3:57 ` [RFA v2 06/13] Allow C-c to work in backtrace in more cases Tom Tromey
2017-08-14 13:20 ` [RFA v2 00/13] various frame filter fixes and cleanups Pedro Alves
2017-08-14 13:57 ` Phil Muldoon [this message]
2017-08-14 14:30 ` Pedro Alves
2017-08-14 13:38 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b88f34a2-f185-852a-515a-d0ed34b766e8@redhat.com \
--to=pmuldoon@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox