From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
To: Simon Marchi <simark@simark.ca>, gdb-patches@sourceware.org
Subject: Re: [RFC 2/5] Implement frame apply [all | COUNT | -COUNT] [-FLAGS...] COMMAND
Date: Sat, 19 May 2018 05:16:00 -0000 [thread overview]
Message-ID: <1526681165.1604.11.camel@skynet.be> (raw)
In-Reply-To: <558abe97-4bae-dc11-a987-2adb7afa0f41@simark.ca>
On Thu, 2018-05-17 at 21:55 -0400, Simon Marchi wrote:
> > +/* Implementation of the "frame apply" command. */
> > +
> > +static void
> > +frame_apply_command (const char* cmd, int from_tty)
> > +{
> > + int count;
> > + struct frame_info *trailing;
> > +
> > + if (!target_has_stack)
> > + error (_("No stack."));
> > +
> > + count = get_number_trailer (&cmd, 0);
> > +
> > + if (count < 0)
> > + {
> > + trailing = trailing_outermost_frame (-count);
> > + count = -1;
> > + }
> > + else
> > + trailing = get_current_frame ();
> > +
> > + frame_apply_command_count ("frame apply", cmd, from_tty,
> > + trailing, count);
> > +}
>
> While testing this, I intuitively expected that this command would
> work the same way as thread apply: take a frame number of frame number
> range. I had to think for a second when this did not do as I expected:
>
> (gdb) bt
> #0 break_here () at test.c:6
> #1 0x000055555555461a in main (argc=1, argv=0x7fffffffde78) at test.c:12
> (gdb) frame apply 0 print 123
> (gdb) frame apply 1 print 123
> #0 break_here () at test.c:6
> $6 = 123
>
> So I'm wondering whether it would make more sense to have both thread apply
> and frame apply work in a similar way, to avoid confusing users.
When I started implementing this, I first intended to have a list
of frames, or range of frames (i.e. similar to thread apply).
However, I finally did the COUNT | -COUNT approach for the following
reasons:
* this is similar to the backtrace command
* the most common use cases are to show all frames,
or some innermost frames, or some outermost frames.
The use case of showing some 'middle frames range' is not a likely
use case (as shown by the backtrace command, that does not have
such feature). Similarly, showing 'cherry picked frames' seems
also unlikely to be useful.
* but the real difficulty is what range syntax to use to indicate
either the innermost N frames or the outermost N frames ?
For the innermost, we could use e.g.
frame apply 0-3 p $sp
to show $sp for frame 0, 1, 2, 3.
But what would be the syntax to print $sp for e.g. 5
outermost frames ?
It is difficult for the user to use "absolute" numbers as
the frame numbering will vary, depending on the stack depth.
And we also have to find a notation to indicate that the range
is at the outermost side. I could not find a reasonable
way to indicate this.
e.g. frame apply -0-4 p $sp
looks an ugly way to indicate the outermost 5 frames.
So, in summary, COUNT | -COUNT has the advantage of being
compatible with backtrace/easy to understand.
Of course, having it similar to backtrace make it not looking
like frame apply. But IMO, that disadvantage is not major, compared
to the other syntax I thought to, which will in any case differ
from the thread apply syntax IMO.
> > +#define FRAME_APPLY_FLAGS_HELP "\
> > +FLAGS letters are v(increase verbosity), q(decrease verbosity)\n\
> > + c(continue), s(silent).\n\
> > +Verbosity (default 2) controls what to print for a frame:\n\
> > + 0 : no frame info is printed\n\
> > + 1 : source line\n\
> > + 2 : location\n\
> > + 3 : location and address\n\
> > + 4 : source line and location\n\
> > +By default, if a COMMAND raises an error, frame apply is aborted.\n\
> > +Flag c indicates to print the error and continue.\n\
> > +Flag s indicates to silently ignore a COMMAND that raises an error\n\
> > +or produces no output."
>
> I would prefer if this was a const char [] rather than a macro.
The macro is used to build a string literal. I quickly tried, but I found
no straightforward way to build a string literal using a factorised
const char [] value.
Philippe
next prev parent reply other threads:[~2018-05-18 22:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-05 19:28 [RFC 0/5] Implenent 'frame apply COMMAND', enhance 'thread apply COMMAND' Philippe Waroquiers
2018-05-05 19:28 ` [RFC 1/5] Add helper functions check_for_flags and check_for_flags_vqcs Philippe Waroquiers
2018-05-18 1:56 ` Simon Marchi
2018-05-18 23:39 ` Philippe Waroquiers
2018-05-19 6:47 ` Simon Marchi
2018-05-19 6:59 ` Philippe Waroquiers
2018-05-05 19:28 ` [RFC 3/5] Add -FLAGS... argument to thread apply Philippe Waroquiers
2018-05-06 19:09 ` Eli Zaretskii
2018-05-05 19:28 ` [RFC 5/5] Announce 'frame apply', faas, taas, tfaas commands and -FLAGS... arg for frame apply Philippe Waroquiers
2018-05-06 19:13 ` Eli Zaretskii
2018-05-05 19:28 ` [RFC 2/5] Implement frame apply [all | COUNT | -COUNT] [-FLAGS...] COMMAND Philippe Waroquiers
2018-05-06 19:16 ` Eli Zaretskii
2018-05-18 1:58 ` Simon Marchi
2018-05-19 5:16 ` Philippe Waroquiers [this message]
2018-05-18 9:46 ` Simon Marchi
2018-05-05 19:28 ` [RFC 4/5] Documentation changes for 'frame apply' and 'thread apply' Philippe Waroquiers
2018-05-06 19:40 ` Eli Zaretskii
2018-05-18 10:42 ` [RFC 0/5] Implenent 'frame apply COMMAND', enhance 'thread apply COMMAND' Simon Marchi
2018-05-18 22:06 ` Philippe Waroquiers
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=1526681165.1604.11.camel@skynet.be \
--to=philippe.waroquiers@skynet.be \
--cc=gdb-patches@sourceware.org \
--cc=simark@simark.ca \
/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