|
From: Nicholas N. <nj...@ca...> - 2004-01-30 16:10:49
|
Hi, Valgrind's usage message is too long; we have so many options. For 99% of users, the debugging options aren't of any interest. Would it be reasonable to omit them by default, and only show them if you specified "-h -h" or "-h -v"? Or maybe "--help-debug"? N |
|
From: Josef W. <Jos...@gm...> - 2004-01-30 17:31:43
|
On Friday 30 January 2004 17:10, Nicholas Nethercote wrote: > Hi, > > Valgrind's usage message is too long; we have so many options. > > For 99% of users, the debugging options aren't of any interest. Would it > be reasonable to omit them by default, and only show them if you specified > "-h -h" or "-h -v"? Or maybe "--help-debug"? I vote for "--help-debug". The usage info should contain at the end words like "Further options for debugging valgrind exist. --help-debug shows a list." Josef |
|
From: Nicholas N. <nj...@ca...> - 2004-01-30 17:38:48
|
On Fri, 30 Jan 2004, Josef Weidendorfer wrote:
> I vote for "--help-debug". The usage info should contain at the end words like
> "Further options for debugging valgrind exist. --help-debug shows a list."
I imagined this:
common user options for all Valgrind tools, with defaults in [ ]:
--tool=<name> Use the Valgrind tool named <name>
--help show this message
* --help-debug show this message, plus debugging options
--version show version
-q --quiet run silently; only print error msgs
-v --verbose be more verbose, incl counts of errors
--trace-children=no|yes Valgrind-ise child processes? [no]
--track-fds=no|yes Track open file descriptors? [no]
N
|
|
From: Nicholas N. <nj...@ca...> - 2004-01-31 22:58:06
|
On Fri, 30 Jan 2004, Nicholas Nethercote wrote:
> I imagined this:
>
> common user options for all Valgrind tools, with defaults in [ ]:
> --tool=<name> Use the Valgrind tool named <name>
> --help show this message
> * --help-debug show this message, plus debugging options
Ok, that's done. However, there are still too many options, mostly
because of the uncommon options:
uncommon user options for all Valgrind tools:
--run-libc-freeres=no|yes Free up glibc memory at exit? [yes]
--weird-hacks=hack1,hack2,... [none]
recognised hacks are: ioctl-VTIME truncate-writes lax-ioctls
--signal-polltime=<time> time, in mS, we should poll for signals.
Only applies for older kernels which need
signal routing [50]
--lowlat-signals=no|yes improve wake-up latency when a thread receives
a signal [no]
--lowlat-syscalls=no|yes improve wake-up latency when a thread's
syscall completes [no]
--pointercheck=no|yes enforce client address space limits [yes]
Since they're all 0.1% cases, I think it would be nice to move all of them
into --weird-hacks (except --signal-polltime, which is hard to do since it
is not a boolean), eg:
uncommon user options for all Valgrind tools:
--weird-hacks=hack1,hack2,... [none]
recognised hacks are: ioctl-VTIME, truncate-writes, lax-ioctls,
libc-freeres, lowlat-sigs, lowlat-syscalls, no-ptrcheck
--signal-polltime=<time> time, in mS, we should poll for signals.
Only applies for older kernels which need
signal routing [50]
Of course, for backwards compatibility, we could let the old invocations
still work. The way --weird-hacks works internally would have to be
changed slightly, eg. into a bit-mask, because it currently only allows
one weird hack at a time.
Comments?
N
|
|
From: Jeremy F. <je...@go...> - 2004-02-01 03:40:46
|
On Sat, 2004-01-31 at 14:58, Nicholas Nethercote wrote: > Of course, for backwards compatibility, we could let the old invocations > still work. The way --weird-hacks works internally would have to be > changed slightly, eg. into a bit-mask, because it currently only allows > one weird hack at a time. > > Comments? That doesn't really help. Just because you put them in weird-hacks, it doesn't mean you don't have to document them (since it's probably a bug that weird-hacks isn't properly documented in the usage message). I've never particularly liked weird-hacks, and I don't think we should extend it. Perhaps we should just add a third set of options: --help-unusual, or something. J |
|
From: Nicholas N. <nj...@ca...> - 2004-02-01 13:34:08
|
On Sat, 31 Jan 2004, Jeremy Fitzhardinge wrote: > That doesn't really help. Just because you put them in weird-hacks, it > doesn't mean you don't have to document them (since it's probably a bug > that weird-hacks isn't properly documented in the usage message). I've > never particularly liked weird-hacks, and I don't think we should extend > it. It does help with the usage message, which is what I want to minimise. The amount of documentation in the manual doesn't worry me. > Perhaps we should just add a third set of options: --help-unusual, or > something. Yeah, sounds alright to me. Reducing the size of the descriptions for the unusual ones would help too; not easy, but could use the approach taken for --partial-loads-ok: "too hard to explain here; see manual" N |