Re: worrying differences in object code due to different build host!

["Greg A. Woods" <woods%planix.ca@localhost>]

On Apr 29, 2015, at 03:50, Martin Husemann <martin%duskware.de@localhost> wrote:

> On Wed, Apr 29, 2015 at 12:40:50AM -0700, Greg A. Woods wrote:
>> One quick test using "objdump -d" doesn't show any difference in the
>> disassembler output even though "size" does show a difference:
> 
> Are you using the same path for source and objects on all machines?
> If you are not doing MKREPRO=yes builds, there will be timestamps
> and pathnames from the build environment embeded in the objects. Also
> path names may influence debug info details.

Historically there has never been anything but instructions and maybe
a few data bytes in the .text section, and I would expect the same
compiler to generate the exact same .text (and .data) sections from the
same source code no matter when or where it is run.  I would expect any
differences from the build environment to only show up in other sections.

However in the real world we've had some very nasty bugs in GCC in the
past which resulted in it generating bad code when it is cross-compiling
from certain build host architectures to certain targets.  If I remember
correctly some of those didn't change the size of the .text section, so
to also see differences in its size was doubly worrying.

I thought those bugs had all been ironed out, but with my recent attempts
to try to find out why I can't build a working XEN3PAE_DOMU i386 kernel
from my own source tree and using my own build hosts I started looking
for possible causes due to my build environment, since I couldn't see any
obvious problems with the source and since I was able to build working
amd64 kernels from the same source and config, and on the same build
hosts.  I.e. the only difference seems to be the target architecture.

The first sanity check I always do with programs built on different
hosts is to make sure their .text sections are the same size, and if so
then I might do a binary comparison if they were not behaving the same.
And now I'm down a different rabbit hole because the reporting tools
are giving what appear to be different answers!

Perhaps these differences can be explained due to different assumptions
about what exactly comprises the ".text" section.

The most interesting clue to the apparent differences so far though
has been that "objdump -d" outputs the exact same disassembler output
even though the .text section seems to have a different size.

I'll do some deeper investigation and look at the assembler output from
the compiler in each build environment when I get a chance and see if
I can explain the different .text sizes without there being any differences
in the execution of the code at runtime.

I'm beginning to think my original problem with a broken i386 kernel is
actually due to a bug in Xen.  In my opinion it is revealing a bug in Xen
even if there's also a bug in the kernel too -- though I'm not 100% sure
where the page fault that's happening should be handled (i.e. in the
hypervisor or in the guest, since it doesn't appear the guest is actually
started yet, but maybe it is).  The dilemma is that a kernel built on an
i386 build host (albeit one running an older NetBSD) also fails the same
way, leaving me with much less of an excuse to blame the amd64-hosted
cross-compiler, even if its generated .text size is different.

-- 
						Greg A. Woods
						Planix, Inc.

<woods%planix.com@localhost>       +1 250 762-7675        http://www.planix.com/