The logic behind the name is that it's not as though the debugger is able to turn aslr on on a system that doesn't have it - so "-aslr on/true/yes" doesn't make sense - but rather the debugger is running on a system with ASLR, in which case the question is whether the debugger should disable it or not for this launch. So --disable-aslr true/false is answering the question "should I disable aslr.
I prefer the true/false to two options, both because of short option namespaces and to keep the help uncluttered. If each on/off option had two entries we'd either have to make the help smart about gathering them together, or the help is going to get really verbose. I'm not opposed to the former, but still... Jim > On Aug 18, 2014, at 1:08 PM, Ed Maste <[email protected]> wrote: > > On 18 August 2014 15:45, Todd Fiala <[email protected]> wrote: >> >> In sum, I'm for either >> >> (1) changing to either `process launch --enable-aslr <true/false>` and >> change the `settings target.disable-aslr' to match the name as the fallback >> setting, or >> >> (2) keeping the target.disable-aslr setting, and extending `process launch >> --disable-aslr` to take true/false. (But - note - this does get into what >> Chandler called out before as being somewhat long in the tooth - `process >> launch --disable-aslr false` when you want ASLR.) > > Ugh, let's avoid the double negative to enable it. > > Is it rare enough that we can just do without the short option as you > said, and have --enable-aslr / --disable-aslr? Or if it's going to > take an argument, drop the 'enable/disable' and have --aslr true / > --aslr false? _______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
