[lldb-dev] Add --enable-aslr flag

[Todd Fiala]

Ok so my mental model of how the default of the disable-aslr occurred was
flawed.

The way things currently work, the disable aslr internal flag is set if
either (1) the lldb target settings have disable-aslr set to true, or (2)
if --disable-aslr is given to the `process launch` command.

So when I tried to implement the --enable-aslr in the process launch
command, it was still seeing that the target setting for disable-aslr was
true, and so it set the disable flag even though the new process launch
setting I had cleared it earlier.

To see the target.disable-aslr setting, you can do this:
```
(lldb) settings show target.disable-aslr
target.disable-aslr (boolean) = true
```

To get the behavior of enabling ASLR, we currently just need to set the
disable-aslr target setting to false:

```
(lldb) settings set target.disable-aslr false
(lldb) settings show target.disable-aslr
target.disable-aslr (boolean) = false
```

Then we get the behavior of having ASLR enabled.

I'm not sure it really makes sense in this case to try to implement
--enable-aslr on the process launch command now that I get the flow of the
target settings, unless we change the model to do something like this:

1. If the process launch command explicitly sets --enable-aslr or
--disable-aslr, do *that*.
2. Otherwise, if the target.disable-aslr setting is true, disable ASLR.
3. Otherwise, we get the default ASLR behavior for the system.

Does that sound reasonable?  I think it makes intuitive sense.  In that
case, the options setting in the process launch command becomes a tri-state
and only if it's unresolved do we go to the target setting.

Thoughts?

-Todd


On Sat, Aug 16, 2014 at 4:44 PM, Chandler Carruth <chandlerc at google.com>
wrote:

>
> On Sat, Aug 16, 2014 at 4:33 PM, Todd Fiala <tfiala at google.com> wrote:
>
>> Hey all,
>>
>> I've got Linux disabling ASLR per default as of a commit in review.  I'm
>> going to follow up with adding an --enable-aslr flag.
>>
>> Do we want to consider removing the --disable-aslr flag since disabling
>> is the default, and it is (perhaps) confusing to have the flag when it
>> currently doesn't change behavior?  I can make an argument for keeping it
>> once I add the --enable-aslr flag, but it's kinda weak.  If you don't
>> specify anything, then it is less clear what you get.  If there's only an
>> enable-aslr flag, then it's a little more clear that ASLR is disabled
>> unless you specifically ask for it.
>>
>> Thoughts?
>>
>
> For heavily scripted things like build systems and compilers, having both
> variants is useful -- you can override decisions made by one set of scripts
> by passing the override, and the last one wins.
>
> But I don't really see any way that applies to a debugger, so yea, I'm
> fine nuking it and just doing --enable-aslr to switch from the default.
>



-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140816/9ffa5c60/attachment.html>