The address breakpoints don't currently resolve to section+offset and then re-resolve themselves that way, though that would be a good addition.
But mostly it avoids the cognitive load of having "the same things be different" when you are going a number of rounds trying to chase a problem down. Jim > On Aug 15, 2014, at 10:03 AM, Zachary Turner <ztur...@google.com> wrote: > > Correct, AFAIK the only way to disable ASLR in Windows is: > > a) Editing a registry setting which will require a reboot and be system-wide > b) Compiling your executable with a specific flag which has been set to > enable ASLR by default since VS 2012. > c) Using the EMET utility (untested, but I guess should work). Regardless, > it's a manual step and would require elevation (aka sudo) > > Maybe it's just because I'm used to an environment where ASLR is per-boot, > but what are the issues with debugging when ASLR is enabled? Source/line > breakpoints can just be resolved every time you debug. Same with symbol > breakpoints. Even absolute address breakpoints can be translated to > Module+offset and persist across ASLR. The only things I can think of off > the top of my head are hardware data breakpoints, and printing addresses to > log files. Is there other stuff that is complicated by ASLR? > > > On Fri, Aug 15, 2014 at 9:49 AM, Todd Fiala <tfi...@google.com> wrote: > > Is ASLR per-launch / per-process on other platforms? > > Linux allows you to set it per process, and based on previous comments, > MacOSX does as well (there's a posix_spawn flag for it on that platform). > You can disable it on Linux at the kernel level, but that's not how we want > to use it in this scenario. > > You don't have a way to disable it just for a process on Windows? > > -Todd > > > On Fri, Aug 15, 2014 at 9:33 AM, Greg Clayton <gclay...@apple.com> wrote: > Yes it should be disabled by default for all systems. It is this was on > MacOSX by default. The linux plug-in will need to be fixed. > > > On Aug 14, 2014, at 9:41 AM, Todd Fiala <todd.fi...@gmail.com> wrote: > > > > [I'm not seeing this show up in the archives two hours after I posted it > > from my google account, so I'm sending it from my gmail account. Pardon if > > this shows up again in the next 24 hours from my @google.com account...] > > > > ---------- Forwarded message ---------- > > From: Todd Fiala <tfi...@google.com> > > Date: Thu, Aug 14, 2014 at 7:29 AM > > Subject: ASLR disabled by default - thoughts? > > To: "lldb-dev@cs.uiuc.edu" <lldb-dev@cs.uiuc.edu> > > > > > > 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?) > > -- > > Todd Fiala | Software Engineer | tfi...@google.com | 650-943-3180 > > -- > > -Todd > > _______________________________________________ > > lldb-dev mailing list > > lldb-dev@cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > -- > 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 > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
