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 <chandl...@google.com> wrote: > > On Sat, Aug 16, 2014 at 4:33 PM, Todd Fiala <tfi...@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 | tfi...@google.com | 650-943-3180
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
