This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC 2/5] Implement frame apply [all | COUNT | -COUNT] [-FLAGS...] COMMAND


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]