In case it helps, I've seen GCC produce different code for function A
when I change function B. This can happen even if function B is not in
the (reasonably close) execution path of function A. However, the
differences I've seen are along the lines of e.g.: using %r10 instead of
%r9, or %r13+3 instead of %r12+4 (where the pointers basically point to
the same desired data). Since both outputs are legal, the differences
can be attributed to the internal state of the compiler which perhaps is
not totally deterministic. Nevertheless, as long as the output is
valid, one should not be able to complain about this variability.
Nevertheless, these changes do expose other bugs. So, if you see these
kind of differences correlated with "the VM crashes" or "the VM appears
to work", then I'd suspect ABI violations with regards to the registers
involved.
On 2/1/11 22:17 , Eliot Miranda wrote:
Hi All,
you may already know that there have been strange stability
problems with the Cog VM on linux. Problems with the heartbeat appear
to derive from specific compilations, one compilation of the same source
producing an executable that will crash, another producing one that
won't. recent testing at Teleplace showed that an effect due to what
was presumed to be a compiler bug (specifically the optimization level
used to compile the heartbeat, high causing a crash) was not repeatable.
So today in building new production VMs for Teleplace I decided to do
three parallel linux builds and see if all produced the same results.
While there are macros used in the source that are date dependent (use
of __DATE__) AFAIA there are none apart from version.c/version.o that
depend on time, and no timestamps or current directory paths in linux
objects, and so, provided different compilations of the same source are
done on the same day, the results should be bit-identical. In my
experiment this turns out not to be the case, which is more than a
little alarming.
What I'm seeing is different results duplicating unixbuild/bld to
unixbuild/bldb and unixbuild/bldc, doing identical configures and makes
in each of the three directories and then comparing resulting objects.
I see this in a bare metal laptop with local sources running CERN SLC5
and on a Parallels VM running CentOS 5.3 (both derived from RHEL). I'm
using gcc 4.1.2. Here's a script that shows example differences:
bld$ for f in *.o vm/*.o; do echo $f;cmp $f ../bldb/$f; cmp $f
../bldc/$f; done
disabledPlugins.o
disabledPlugins.o ../bldb/disabledPlugins.o differ: byte 200, line 4
disabledPlugins.o ../bldc/disabledPlugins.o differ: byte 200, line 4
version.o
version.o ../bldb/version.o differ: byte 166, line 3
version.o ../bldc/version.o differ: byte 166, line 3
vm/aio.o
vm/cogit.o
vm/debug.o
vm/gcc3x-cointerp.o
vm/osExports.o
vm/sqExternalSemaphores.o
vm/sqHeapMap.o
vm/sqLinuxHeartbeat.o
vm/sqLinuxWatchdog.o
vm/sqLinuxWatchdog.o ../bldb/vm/sqLinuxWatchdog.o differ: byte 33, line 1
vm/sqLinuxWatchdog.o ../bldc/vm/sqLinuxWatchdog.o differ: byte 33, line 1
vm/sqNamedPrims.o
vm/sqNamedPrims.o ../bldb/vm/sqNamedPrims.o differ: byte 6346, line 30
vm/sqNamedPrims.o ../bldc/vm/sqNamedPrims.o differ: byte 6346, line 30
vm/sqTicker.o
vm/sqUnixCharConv.o
vm/sqUnixExternalPrims.o
vm/sqUnixMain.o
vm/sqUnixMain.o ../bldb/vm/sqUnixMain.o differ: byte 31415, line 170
vm/sqUnixMain.o ../bldc/vm/sqUnixMain.o differ: byte 31414, line 170
vm/sqUnixMemory.o
vm/sqUnixThreads.o
vm/sqUnixVMProfile.o
vm/sqVirtualMachine.o
Using objdump --disassemble I can see for example that sqLinuxWatchdog.o
and sqUnixMain.o differ only in the symbol table, not the executable
code. So perhaps this is not meaningful, and merely noise. But with
simple files like disabledPlugins.c that different objects are produced
at all in different runs is rather worrying:
bld$ cat disabledPlugins.c
/* this should be in a header file, but it isn't. ho hum. */
typedef struct {
char *pluginName;
char *primitiveName;
void *primitiveAddress;
} sqExport;
sqExport vm_display_Quartz_exports[] = { 0, 0, 0 };
sqExport vm_display_custom_exports[] = { 0, 0, 0 };
sqExport vm_display_fbdev_exports[] = { 0, 0, 0 };
sqExport vm_sound_MacOSX_exports[] = { 0, 0, 0 };
sqExport vm_sound_NAS_exports[] = { 0, 0, 0 };
sqExport vm_sound_OSS_exports[] = { 0, 0, 0 };
sqExport vm_sound_Sun_exports[] = { 0, 0, 0 };
sqExport vm_sound_custom_exports[] = { 0, 0, 0 };
I wonder
- do you see the same effect?
- does this happen with gcc versions other than 4.1.2?
- does it happen on non-RHEL-derived distros?
- is this a meaningful signal or just harmless noise?
- what am I doing wrong?
Clearly I need to look more carefully but I thought I'd ask y'all in
order to understand and hopefully solve the build instabilities as
swiftly as possible.
If you do want to try and reproduce this simply duplicate the build
directory (unixbuild/bld in the Cog VM source) twice and do three
separate configures and makes, one in each of the build directories,
each from the same source code. Then run some variation fo the script
above to compare the object files so produced.
best
Eliot
