Re: RFC: seemingly gratuitous changes introduced by kkh 9.0-1
On Sun, 6 May 2012, Robert Millan wrote:
It seems that my latest changes in kfreebsd-kernel-headers (9.0-1, now
in experimental) have some strange effect in glibc.
My changes are only cleanup and addition of new upstream headers.
Their purpose is only for self-consumption (i.e. other headers of kkh
need them). However even in the event that some of these are
indirectly included in glibc build, none of the definitions of these
headers conflicts with anything in glibc headers. In fact even the
glibc build log stays the same.
In spite of this, the resulting binaries are different. I've
dissassembled and manually inspected them, and I found that many of
those changes are cosmetical! For example, GCC generates equivalent
instructions in a different order. Or it reverses the arguments in a
"cmpl" instruction and compensates for that by also reversing the jump
I'm not sure what can be done about this. I've been looking at the
problem for more than two weeks and haven't been able to figure out
why we're getting different results. If we could find an actual
problem, it'd be much easier to pinpoint it, but in this situation I'm
just seeing how source changes that look completely harmless (e.g. add
a #include <sys/types.h>) cause binary changes which also look
harmless, but it's pretty scary not to have any explanation for them.
I've put an objdump diff all *.o files in build-tree here:
Any ideas on what to do?
I does not look like there is a real problem.
The gcc definitely uses internally some hashes, which under even
slightly different source files would be different. The simple inclussion of
additional definition at least changes line numbers in preprocessed
source and sequence number of a defined type.