ASLR disabled by default - thoughts?

Hey all,

Regarding this bug:
http://llvm.org/bugs/show_bug.cgi?id=20658

We’ve been discussing the idea of having ASLR disabled by default when launching processes within lldb. Currently it looks like the default behavior is to have it enabled, and require explicitly disabling to get that behavior for the process.

It seems like it might make more sense to have it disabled by default - that way code references would likely be static across debugger runs, which seems to be more what we want when tracking down issues across code runs.

Any thoughts on this?

The counterargument I could make for changing it would be (aside from legacy compatibility issues perhaps on the MacOSX/iOS side) - taking the exe out of its native state on the OS. If a bug is ASLR sensitive, the user might miss it. And so behavior in the debugger could differ from the exe in its native state. Not sure how relevant that is for the majority of usages, though.

I’ll be fixing the fact that Linux is ignoring this altogether. But while I’m in there, I could flip the default if we wanted to do it. If not globally, we’d probably pursue defaulting it on Linux (and Ed seems to like it for FreeBSD as well, so maybe for not Apple in that case?)

Hey all,

Regarding this bug:
http://llvm.org/bugs/show_bug.cgi?id=20658

We've been discussing the idea of having ASLR disabled by default when
launching processes within lldb. Currently it looks like the default
behavior is to have it enabled, and require explicitly disabling to get
that behavior for the process.

It seems like it might make more sense to have it disabled by default -
that way code references would likely be static across debugger runs, which
seems to be more what we want when tracking down issues across code runs.

Any thoughts on this?

My strong preference: disable ASLR by default.

1) It matches the behavior of most debuggers today.
2) There are not many options when a bug vanishes under the debugger: ASLR,
threading interactions, or ptrace behavior changes (or equivalent on any
other platform). I don't think this is hard for someone to realize.

Also, please fix the spelling of the flag here. '--disable-aslr=False'
would be... a really terrible interface. ;]

The counterargument I could make for changing it would be (aside from
legacy compatibility issues perhaps on the MacOSX/iOS side) - taking the
exe out of its native state on the OS. If a bug is ASLR sensitive, the
user might miss it. And so behavior in the debugger could differ from the
exe in its native state. Not sure how relevant that is for the majority of
usages, though.

I think this is both rare and easy to diagnose as indicated above.

I'll be fixing the fact that Linux is ignoring this altogether. But while
I'm in there, I could flip the default if we wanted to do it. If not
globally, we'd probably pursue defaulting it on Linux (and Ed seems to like
it for FreeBSD as well, so maybe for not Apple in that case?)

Thanks!

Turning off ASLR is the default on Mac OS X. It drives you nuts not to have it off, and a chorus of voices (ours among them) demanded it be turned off in the debugger by default when it first showed up on OS X. That was back in the gdb days, and we carried the behavior over to OS X.

Jim

I believe that disabling by default would match the gdb behavior yes? If nothing else, yes, I’m a fan of this :slight_smile:

-eric

I’d agree with the default behavior being off and the command being changed to an enable style. All targets we have worked with certainly default to off, or don’t have the feature at all.

Colin

Thanks all.

I’m going to start looking into this today.

FWIW, once I get debugging working on Windows, I’m going to disable this setting entirely as it doesn’t make sense on Windows. Is ASLR per-launch / per-process on other platforms? At least on Windows it’s per-boot, so if ASLR is enabled for a particular process, everything will be the same until you reboot.

On Mac OS X it is part of the launch flags.

Jim

Note, while I appreciate the elegance of not having options that don't make sense for a particular platform note that it will mean that if I'm used to working on say Linux, and I put:

command alias run process launch -A --

in my .lldbinit, then move over to windows and carry my .lldbinit with me, my run command will no longer work. So there's a trade-off between cleanliness and portability here...

Jim

Well, more like what I mean is that I would just log a warning that says “Option not supported on this platform”. I wouldn’t make it crash.

That would be fine. I thought you meant removing the option for Windows - IIRC you added the facility to do that a while ago... That wouldn't cause a crash, but it would break the alias, and then I'd have to go fix it on the Windows side (and repeat every time I moved my init files around.)

Jim