> On Aug 18, 2014, at 12:45 PM, Todd Fiala <[email protected]> wrote:
> 
> On Mon, Aug 18, 2014 at 11:22 AM,  <[email protected]> wrote:
> I don't think we have any other instances where we use two flags to express 
> "do x" and "don't do x".
> For the long options is isn't such a big deal but we try not to use up more 
> short options than necessary, since this gets to be a crowded space.
> 
> I'd be happy to use long-option only here.
>  
>   Maybe "process launch --enable-aslr <true/false>", which mirrors the 
> setting anyway?
> 
> 
> Sounds good.  But the fallback behavior when process launch doesn't specify 
> anything is currently to disable ASLR if the target.disable-aslr setting is 
> true.  Are you interested in reversing that setting to enable-aslr?  If not, 
> then maybe we go with just extending 'process launch --disable-aslr 
> <true/false>'.
> 
> 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.)

I like option 2.  You generally aren't turning on aslr, that's something the 
system does or does not have on.  You're disabling the system's aslr for this 
launch.  So I think disable is right.  As for the length of the command, either 
this isn't going to be something you type often (and even if you are you'll 
type:

pr la --d 0

) or if you use it a lot, you'll make an alias for it.


> 
> Thoughts on that?  I'll code up whatever we decide on.
> 
> If backward  compat for option (1) is a concern, we could continue to accept 
> `settings set disable-aslr <true/false>` and just have it do the right thing.
> 
> -Todd
>  
> Jim
> 
> > On Aug 17, 2014, at 10:48 PM, Todd Fiala <[email protected]> wrote:
> >
> > This change modifies the logic used to set the eLaunchFlagDisableASLR 
> > ProcessLaunchInfo setting for inferior process launching.  Now, if 'process 
> > launch' is provided with either --disable-aslr or --enable-aslr, then the 
> > launch flag is set accordingly.  If niether --disable-aslr or --enable-aslr 
> > are specified, then the setting for target.disable-aslr is used to 
> > determine the setting or clearing of the eLaunchFlagDisableASLR setting.  
> > The target.disable-aslr setting currently defaults to true, so the default 
> > behavior when nothing is specified on the 'process launch' (i.e. 'run' 
> > command) is to disable ASLR.
> >
> > --
> > -Todd
> > <tfiala_enable-aslr.diff>_______________________________________________
> > lldb-commits mailing list
> > [email protected]
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
> 
> _______________________________________________
> lldb-commits mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
> 
> 
> 
> -- 
> Todd Fiala |   Software Engineer |     [email protected] |     650-943-3180

_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits

Reply via email to