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