Add --enable-aslr flag

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.


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.

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.



Sounds good, but we should also *error* if an attempt to launch a process
is made with either setting when that setting is unsupported on the system.
Or at least a stringent warning.