For now, I'd suggest that we don't deal with ASLR, and we lose some incremental build support for compilers that are non-deterministic.
As far as I can tell, this will only have an effect in this scenario: - A source file or any of it's included headers (loaded transitively) *has changed* since the last time we compiled - The change to these source inputs *has no real effect on the output* (for example removing a comment from the end of a line, or adding an irrelavent compiler flag) - The compiler we are using is *non-deterministic* Later I think that modelling this might be the way to go. For GCC the implementation of 'determinism' might be to use '-frandom-seed', whereas on clang/linux we might need to resort to something more drastic (like you have on CI). We could also fail if the toolchain is not able to produce deterministic output (when required). We might be able to detect determinism in the compiler by compiling a sample source file multiple times: this source contain elements known to invoke randomisation. Daz On Tue, Feb 25, 2014 at 12:32 AM, Rene Groeschke <gra...@breskeby.com>wrote: > Hey guys, > > while working on the gradle native support I've noticed some issues with > incremental builds. > > I've added an implementation of the > AbstractLanguageIncrementalBuildIntegrationTest For ObjectiveC and > Objective-CPP, which works without problems with gcc and with clang on > osx, but I noticed randomly failing tests when using clang on ubuntu. > After some digging I noticed that the generated object files can differ, > even when created from exactly the same sources/flags. > > When comparing the according assembler code, I see that the address > space is chosen randomly (see. diff here: http://pastebin.com/uY1LERGX). > This behavior comes from a security feature called ASLR (Address space > layout randomization). Toget our tests to pass on every invocation, I > needed to disable ASLR by globally configuring it through > /proc/sys/kernel/randomize_va_space (0 for disabling, 2 for enabling, 1 > for "conservative randomization) or by disabling it locally via "> > setarch `uname -m` -R /bin/bash". > > So, ASLR breaks our incremental builds because the generated object > files can differ. > > I havn't yet figured out why ASLR currently does not affect our c / c++ > integration tests with clang. Maybe the code that we're using doesn't invoke address-randomisation: if we had more sophisticated test code it might expose this. > There are also a bunch of raised bugs that > prevents/prevented llvm to be complete deterministic. Some of them were > already solved in newer llvm versions. To get the incremental build > running we would need to be able to disable ASLR in our native > toolchains. Of course this comes with the cost of less secure output > that ASLR introduced. > > I see 3 options at the moment: > > - don't deal with ASLR at all with the cost of possibly loosing > incremental build support. > - always disable ASLR if possible to have deterministic builds (with the > cost of loosing ASLR introduced security). > - model this in our toolchains to allow enabling/disabling ASLR support. > > Thoughts? > > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
