Checking same object files produced

Posted Jul 26, 2012 10:59 UTC (Thu) by epa (subscriber, #39769)
Parent article: The UAPI header file split

I imagine that rearranging some header files will not change the generated code. So the correctness check can be making sure that the resulting kernel image is byte-for-byte identical (for various sets of config flags). The review process then isn't to check correctness of each line of patch, but to approve the general idea.

Checking same object files produced

Posted Jul 26, 2012 11:39 UTC (Thu) by NRArnot (subscriber, #3033) [Link] (2 responses)

That's assuming the compiler is perfectly well-behaved. It might be that the different ordering of #define statements changes the internal state of the compiler, leading to a change in the ordering of entities which are present in the generated code. The binary code would then be functionally identical but not byte-for-byte identical.

Checking same object files produced

Posted Jul 26, 2012 12:28 UTC (Thu) by ms (subscriber, #41272) [Link]

Take the generated assembly before and after and prove it's equivalent? Yes, I'll fetch my coat...

Checking same object files produced

Posted Jul 27, 2012 11:17 UTC (Fri) by nix (subscriber, #2304) [Link]

Given that the only #defines this code should be altering are those related to multiple-inclusion guards, I think we could describe any such ordering changes as a compiler bug. That is not to say that no such bugs exist, but it is likely that they'd also lead to inconsistent code generation when faced with identical output, and cause failures in GCC bootstrap comparison. (This has happened before, e.g. with optimizations depending on the ordering of pieces of compiler state in hash tables -- the infamous 'hashing by
address' bug class -- and that sort of thing.)