Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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



  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