Feedback about users/palves/cli-options

Philippe Waroquiers philippe.waroquiers@skynet.be
Sat May 18 10:35:00 GMT 2019


On Fri, 2019-05-17 at 18:02 +0100, Pedro Alves wrote:
> On 5/17/19 3:48 PM, Pedro Alves wrote:
> > On 5/17/19 1:50 PM, Pedro Alves wrote:
> > > > * bt accepts now 2 'counts' to  limit on the nr of frame to show.
> > > >   This is a little bit confusing, so maybe the interactions between
> > > >   the 2 might be explained in the help.
> > > >   E.g. explain that the below will only give 2 frames:
> > > >     bt -limit 2 3
> > > > 
> > > 
> > > I haven't addressed this one yet -- I'm thinking that maybe we should
> > > just drop that option?
> > 
> > And after re-reading again, I think this is the only bit that I
> > haven't addressed?
> > 
> > I'll try to remove the option, see how it looks.
> 
> That was easy.  I've pushed a patch to the branch.
> 
> Thanks,
> Pedro Alves

I have re-checked with the last state 4397e95d5f213937af6748c9df098b8d546182d7.
Everything works as expected, except that 'help thread apply'
still speaks about frame information.

Some further possible fine tuning:
* The behaviour for 'frame|thread apply' in case of error could be better
  explained in the help, as '-c' speaks from an error without referring to COMMAND.
  What about:
   -c
     Print the error raised by a COMMAND and continue.

* For 'number options' (such as -elements): we could (similarly to boolean options)
  make the value optional, meaning unlimited by default, e.g.

  -array-indexes [on | off]
    Set printing of array indexes.

  -elements [NUMBER | unlimited]
    Set limit on string chars or array elements to print.
    No value or "unlimited" causes there to be no limit.

Effectively, if I do not give a limit after -elements, there is no limit :).

Philippe



More information about the Gdb-patches mailing list