<div dir="ltr">Great, thanks!</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 18, 2014 at 3:22 PM, <span dir="ltr"><<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
> On Aug 18, 2014, at 3:18 PM, Todd Fiala <<a href="mailto:tfiala@google.com">tfiala@google.com</a>> wrote:<br>
><br>
> On Mon, Aug 18, 2014 at 2:47 PM, <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br>
><br>
> > On Aug 18, 2014, at 12:45 PM, Todd Fiala <<a href="mailto:tfiala@google.com">tfiala@google.com</a>> wrote:<br>
> ><br>
> > On Mon, Aug 18, 2014 at 11:22 AM, <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br>
> > I don't think we have any other instances where we use two flags to express "do x" and "don't do x".<br>
> > 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.<br>
> ><br>
> > I'd be happy to use long-option only here.<br>
> ><br>
> > Maybe "process launch --enable-aslr <true/false>", which mirrors the setting anyway?<br>
> ><br>
> ><br>
> > 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>'.<br>
> ><br>
> > In sum, I'm for either<br>
> ><br>
> > (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<br>
> ><br>
> > (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.)<br>
><br>
> 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.<br>
><br>
> Yeah, I started having pangs of a potential misleading option that requires more explaining when I wrote this comment in the patch:<br>
><br>
> // Determine whether we will disable ASLR or leave it in the default state (i.e. enabled if the platform supports it).<br>
><br>
> So I think disable is right.<br>
><br>
> I am logically behind that argument. I talked to Ed Maste earlier today as I had done some research on this over the weekend on FreeBSD and found that it was still in patch state (i.e. not part of FreeBSD proper). So there it definitely would be always disabled, because the default state is "not there". Enable would certainly be misleading there. Chandler made the argument for emitting a warning/error in that case (i.e. you're asking for something that cannot be).<br>
><br>
> Probably the conceptual dislike here is we have a disable mechanism but the disable is the default. So shutting off the disable is saying disable = no. Just a bit wordy. But accurate.<br>
><br>
><br>
> 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.<br>
><br>
> Let's just leave it at that. I'll adjust. So, to make sure I understand, are we keeping the -A for that as the short option? (I think yes, and we're just getting rid of the --enable-aslr since this will be --disable-aslr false).<br>
><br>
<br>
</div>Yes, that seems right to me.<br>
<span class="HOEnZb"><font color="#888888"><br>
Jim<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> -Todd<br>
><br>
> 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:<br>
><br>
> pr la --d 0<br>
><br>
> ) or if you use it a lot, you'll make an alias for it.<br>
><br>
><br>
> ><br>
> > Thoughts on that? I'll code up whatever we decide on.<br>
> ><br>
> > 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.<br>
> ><br>
> > -Todd<br>
> ><br>
> > Jim<br>
> ><br>
> > > On Aug 17, 2014, at 10:48 PM, Todd Fiala <<a href="mailto:todd.fiala@gmail.com">todd.fiala@gmail.com</a>> wrote:<br>
> > ><br>
> > > 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.<br>
> > ><br>
> > > --<br>
> > > -Todd<br>
> > > <tfiala_enable-aslr.diff>_______________________________________________<br>
> > > lldb-commits mailing list<br>
> > > <a href="mailto:lldb-commits@cs.uiuc.edu">lldb-commits@cs.uiuc.edu</a><br>
> > > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits</a><br>
> ><br>
> > _______________________________________________<br>
> > lldb-commits mailing list<br>
> > <a href="mailto:lldb-commits@cs.uiuc.edu">lldb-commits@cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits</a><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Todd Fiala | Software Engineer | <a href="mailto:tfiala@google.com">tfiala@google.com</a> | <a href="tel:650-943-3180" value="+16509433180">650-943-3180</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Todd Fiala | Software Engineer | <a href="mailto:tfiala@google.com">tfiala@google.com</a> | <a href="tel:650-943-3180" value="+16509433180">650-943-3180</a><br>
<br>
</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>