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: [RFA_v2 2/8] Implement frame apply [all | COUNT | -COUNT] [FLAGS...] COMMAND.


On 06/15/2018 12:01 AM, Philippe Waroquiers wrote:
> On Wed, 2018-06-13 at 20:52 +0100, Pedro Alves wrote:
>>  Implement frame apply [all | COUNT | -COUNT] [OPTION]... COMMAND.
>>
>> Same comments apply to the "thread apply" patch too, of course.
>>
>>> Also implement the command 'faas COMMAND', a shortcut for
>>> 'frame apply all -s COMMAND'.
>>>
>>> Note: the syntax of 'frame apply' to specify some innermost or outermost
>>> frames is similar to 'backtrace' command.
>>> An alternative could be to make 'frame apply' similar to
>>> 'thread apply'. This was not chosen as:
>>>   * the typical use cases for frame apply are all/some innermost/some outermost
>>>     frames.
>>>   * a range based syntax would have obliged the user to use absolute numbers
>>>     to specify the outermost N frames, which is cumbersone.
>>>     Or an syntax different from the thread range would have been needed
>>>     (e.g. -0-4 to specify the 5 outermost frames).
>>> So, making frame apply similar to backtrace is found better.
>>
>> Hmm, I played with this a bit now, AFAICT, this syntax forces the applicable
>> range to start at either the innermost or outermost?  How does one e.g., apply
>> the command to frames 10 to 20 (because e.g., they are the frames that
>> are running some library code), when there exist frames 0-50?  
>>
>>>
>>> Th new command 'frame apply' allows to apply a COMMAND to a number of frames,
>>> or to all frames.
>>
>> This stands out as a limitation to me.
> Yes, it allows to (only) do what backtrace allows, and so, similarly
> to backtrace, does not allow to 'cherry pick' frames (or range of frames).
> 
> I initially tried to find a reasonable syntax to allow a range based
> selection of frames, but could not obtain anything intuitive to specify
> the outermost N frames.
> 
> Assuming no better syntax is found, maybe we need to explain better
> in the user manual that 'frame apply' selection of frame is similar/compatible
> with backtrace, maybe something like:
>     'frame apply' uses the same convention as 'backtrace' to specify the
>     frames to apply COMMAND on : N innermost frames, or N outermost frames,
>     or all frames.
>     Note that 'thread apply' uses  a list of thread IDs or thread IDs range.
> 
> I understand that the differences is not ideal, but IMO, there
> are inherent differences between thread and frames, making it difficult
> to use a common syntax for 'frame lists' and 'thread lists'.
> E.g. there is no concept of innermost/outermost thread list, while
> I think we need a syntax for this concept in 'frame apply'.
> 
> So, in summary, would be fine for me to change 'frame apply'
> for a better syntax, but which better syntax allows to specify
> as intuitively as backtrace N outermost frames ?
> 
> And if we have another syntax than backtrace, then it should be
> similar to thread apply THREADID ranges, otherwise that would be very
> confusing.
> => I do not see a syntax consistent with thread apply ID ranges
> or individual IDs, that would allow to specify N innermost or
> outermost frames.

Hmm, maybe the problem is with the trying to fit two concepts
into the same syntax.

"backtrace" suggests in its name a trace of calls going
back.  When you think of filtering the output, you're usually
interested in some number of innermost frames leading up to the
current frame, so an optional count argument there seems kind
of natural.

Note also that you can do "bt" without a COUNT argument,
again given that order is inherent to the command.

But you can't do that with "frame apply", like:
  (gdb) frame apply COMMAND
at least not in your implementation.

(Funnily you get no error if you try it.)

For "frame apply", a count doesn't seem to fit as
naturally to me.  But that might be because I was
drawing the parallel to "thread apply".  I do see
the argument for modeling on "backtrace".

Maybe we could have this (1):

 frame apply all COMMAND
 frame apply 1 3 5 7-9 100 COMMAND
 frame apply count [COUNT | -COUNT] COMMAND

Or if we go with number == count by default, this (2):

 frame apply all COMMAND
 frame apply [COUNT | -COUNT] COMMAND
 frame apply id 1 3 5 7-9 100 COMMAND

I think I'd mildly prefer option (1) above.  It'd avoid
having to decide whether to spell it "id" or "level"
too.  :-)  But both ways are fine with me.

Note, instead of "count", we could have for example:

 frame apply inner N COMMAND
 frame apply outer N COMMAND

dunno.

I could also see adding different kinds of filters
in the future, like, e.g., applying a command to
frames running function FUNCTION:

 frame apply function FUNCTION COMMAND

Or apply a command to frames running on a library or
executable FILE:

 frame apply objfile FILE COMMAND

Though it could also make sense to be able to combine
the filters, like:

 frame apply all -function foo -objfile FOO -whatnot BAR COMMAND

which might be a little to far into over-engineeringland.  Not sure.
Maybe not.

> 
>>
>> I played with this a bit, and I have to admit that I found the
>> -v / -q combinations, and relativeness of the "quietness/verbosity"
>> level, a bit unintuitive and confusing.
>>
>> E.g.,:
>>
>>  (top-gdb) frame apply 2 echo
>>  #0  0x00007ffff54e0c6b in __GI___poll (fds=0x1a343d0, nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
>>  #1  0x00000000007083e4 in gdb_wait_for_event (block=1) at src/gdb/event-loop.c:771
>>
>>  (top-gdb) frame apply 2 -q echo
>>  0x00007ffff54e0c6b      29        return SYSCALL_CANCEL (poll, fds, nfds, timeout);
>>  0x00000000007083e4      771           num_found = poll (gdb_notifier.poll_fds,
>>  (top-gdb) 
>>
>> Here, "-q" didn't make the output really be quieter, only different.
> Yes, the verbosity just controls the choice of the value of
> frame.h enum print_what:
>  enum print_what
>   { 
>     /* Print only the source line, like in stepi.  */
>     SRC_LINE = -1, 
>     /* Print only the location, i.e. level, address (sometimes)
>        function, args, file, line, line num.  */
>     LOCATION,
>     /* Print both of the above.  */
>     SRC_AND_LOC, 
>     /* Print location only, but always include the address.  */
>     LOC_AND_ADDRESS 
>   };
> 
> and that is not really a 'monotonically increasing function'.

Yeah.


>> Consider also if we add a knob to tweak the default verbosity.
>> Like "set frame-apply-default-format N" or whatever.
>> With that, "frame apply -q" does a different thing depending on
>> the value of the default setting.
>>
>> So I'm wondering whether "frame apply -quiet/-source/-location/-etc."
>> options wouldn't be better.  
>>
>> Or "frame apply -format [0-4]" and/or 
>> "frame apply -format quiet/source/location/location".
>>
>> Maybe alternatively consider ditching the format ideas, and have
>> users combine "frame apply -q" with "list" if they want to see
>> sources.  OK, I expect resistance to that idea.  :-)
> 
> Not too much resistance on my side to drop the format idea :).

Eh. :-)

> 
> On a second thought, this verbosity looks all too 'over-engineered' :
>   thread apply verbosity currently only allows to print nothing
>     or a fixed set of information per thread
>   backtrace prints a fixed information per frame
>   frame apply allows to choose whatever in enum print_what with
>     non intuitive verbosity control.
> 
> => I suggest to then just have the -q option : by default,
> frame information is printed like backtrace, and if -q is given,
> no information is printed.
> And same for 'thread apply' : by default, it prints a fixed
> set of info. And -q means do not print it.
> (we for sure need at least the -q to allow only the thread/frame info
> to be
> printed for successful COMMAND).
> 
> (again, in the future, we can if we want add other options
> to control what to print, if we really need this flexibility).
> 
> So, what do you think about the (simpler) idea of just having
>   -q for both thread apply and frame apply ?

I like it.  :-)  As you say, we can always think more about
this later and add ability to fine tune in the future.

Thanks,
Pedro Alves


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