I've been investigating some LTO-related test failures in a GCC port for
a DSP target that has not yet been submitted to the FSF. The bug I've
hit looks like the same issue with spurious multiple definitions that
was previously reported on the gcc-help list:
http://gcc.gnu.org/ml/gcc-help/2011-10/msg00201.html
for an ARM EABI target with RTEMS.
I've been trying to duplicate the failure with some other target that
can be tested "off the shelf". I haven't found an actual failure yet,
but I think I see what is causing it. Here's the analysis I came up
with using a powerpc-none-eabi target.
I added some instrumentation to ld to make it print out the files it was
loading from the output of the LTO plugin. Building
powerpc-none-eabi-gcc
/scratch/sandra/fsf-mainline/src/gcc-mainline/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1.c
/scratch/sandra/fsf-mainline/src/gcc-mainline/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1-lib.c
/scratch/sandra/fsf-mainline/src/gcc-mainline/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c
-w -O2 -flto -msim -lm -save-temps -Wl,-Map=foo.map
told me:
Loading
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/ecrti.o
OPEN_BFD_NORMAL
Loading
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/../../../../powerpc-none-eabi/lib/sim-crt0.o
OPEN_BFD_NORMAL
Loading
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/crtbegin.o
OPEN_BFD_NORMAL
Loading 20010124-1.o OPEN_BFD_NORMAL
Loading 20010124-1-lib.o OPEN_BFD_NORMAL
Loading main.o OPEN_BFD_NORMAL
Loading
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/../../../../powerpc-none-eabi/lib/libm.a
OPEN_BFD_NORMAL
Loading
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/libgcc.a
OPEN_BFD_NORMAL
=start group
Loading
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/../../../../powerpc-none-eabi/lib/libsim.a
OPEN_BFD_FORCE
Loading
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/../../../../powerpc-none-eabi/lib/libc.a
OPEN_BFD_FORCE
=end group
Loading
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/libgcc.a
OPEN_BFD_NORMAL
Loading
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/crtend.o
OPEN_BFD_NORMAL
Loading
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/ecrtn.o
OPEN_BFD_NORMAL
Loading /tmp/ccxgHMEr.ltrans0.ltrans.o OPEN_BFD_NORMAL
Note that this last file includes a local definition of memcpy,
originally from 20010124-1-lib.c. The thing that seems to be leading to
the multiple definition error is that the startup code for my target,
and apparently the startup code for the RTEMS target too, includes a
reference to memcpy, which is resolved to the version from libc.a
*before* the linker sees the one from the *.ltrans.o file at the end of
the list.
I'm still finding my way around LTO; can anyone who's more familiar with
this help narrow down where to look for the cause of this? I don't even
know if this is a compiler or ld bug at this point. I'm not sure I can
justify spending a lot of time working on this, but I'd at least like to
get a proper bug report with an easily reproducible test case filed in
the appropriate Bugzilla. I looked around and didn't see that the
previous report of this bug on gcc-help@ ended up recorded anyplace that
the LTO gurus were likely to remember or do anything about it. :-S
-Sandra
