<div dir="ltr">Ok so my mental model of how the default of the disable-aslr occurred was flawed.<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>To see the target.disable-aslr setting, you can do this:</div><div><div>```</div><div><div>(lldb) settings show target.disable-aslr</div><div>target.disable-aslr (boolean) = true</div></div><div>```</div>
<div><br></div></div><div>To get the behavior of enabling ASLR, we currently just need to set the disable-aslr target setting to false:</div><div><br></div><div>```<br></div><div><div>(lldb) settings set target.disable-aslr false</div>
<div>(lldb) settings show target.disable-aslr</div><div>target.disable-aslr (boolean) = false</div></div><div>```</div><div><br></div><div>Then we get the behavior of having ASLR enabled.</div><div><br></div><div>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:</div>
<div><br></div><div>1. If the process launch command explicitly sets --enable-aslr or --disable-aslr, do *that*.<br></div><div>2. Otherwise, if the target.disable-aslr setting is true, disable ASLR.</div><div>3. Otherwise, we get the default ASLR behavior for the system.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Thoughts?</div><div><br></div><div>-Todd</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Aug 16, 2014 at 4:44 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class=""><br><div class="gmail_quote">On Sat, Aug 16, 2014 at 4:33 PM, Todd Fiala <span dir="ltr"><<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey all,<div><br></div><div>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.</div>

<div><br></div><div>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.</div>


<div><br></div><div>Thoughts?</div></div></blockquote></div><br></div>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.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div></div>

</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small">
<td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a> |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"><font color="#1155cc"> <a>650-943-3180</a></font></td></tr></tbody></table><br></div>
</div>