Cross-compiler builds but results fail in crt1.o ...?

[Paul Smith <paul@xxxxxxxxxxxxxxxxx>]

Hi all.

I've created a cross-compiler environment that appears to work well for
the most part, but clearly there's something not right with it.  I've
poked and prodded it for a while but I can't come up with anything.

I'm running the compiler on GNU/Linux Intel and my cross-environment is
also GNU/Linux Intel, but a different version.  I have built the
compiler using a Canadian cross procedure, where the host is GNU/Linux
RHEL5 Intel 32bit and the target is a generic GNU/Linux Intel system,
supporting both 32 and 64bit output.

The bad news is I'm using GCC 4.2.4 and binutils 2.18.  Unfortunately
it's not practical for me to upgrade right now (next release...).  I
know that it's possible to use these versions because I was using them
before, with an incorrect compiler build procedure that didn't have the
problem below (unfortunately it ALSO didn't create libstdc++.so with
version information, due to not detecting GNU ld etc., which meant that
I couldn't link some 3rdparty C++ shared libraries... hence this attempt
to rebuild the compiler "correctly").

When I run the compiler I'm using --sysroot pointing at a Red Hat EL 6
sysroot containing both 32bit and 64bit libraries in typical multilib
config.

I can give lots of gory details, but I'm hoping someone can help me
narrow down my search before I get too deep.  See if the behavior below
creates any suspicions:

Here's a simple program:

        struct foo { char app[128]; };
        int main(void) { struct foo x = {0}; return 0; }

The trick here is the struct needs to contain an array; simple integers
don't cause any problems; you'll see why below.  If I build this as a
64bit program (the default) then it works (FWIW I'm building this on
RHEL 6.2):

        $ x86_64-generic-linux-gnu-gcc --sysroot=/cc/sysroot -o foo /tmp/foo.c
        $ LD_LIBRARY_PATH=/cc/sysroot/lib64 ./foo

But, if I build it as a 32bit application, then it dumps core
immediately in some internal code:

        $ x86_64-generic-linux-gnu-gcc --sysroot=/cc/sysroot -m32 -o foo /tmp/foo.c
        $ LD_LIBRARY_PATH=/cc/sysroot/lib ./foo
        Segmentation fault
        
        $ LD_LIBRARY_PATH=/cc/sysroot/lib gdb ./foo
            ...
        Program received signal SIGSEGV, Segmentation fault.
        0x080496e0 in ?? ()
        (gdb) bt
        #0  0x080496e0 in ?? ()
        #1  0x00127cc6 in __libc_start_main () from /cc/sysroot/lib/libc.so.6
        #2  0x08048301 in _start ()

It also works if I build it 32bit using c++ with static libstdc++... but
not dynamic C++!  Weird!

If I change the code to this:

        struct foo { char app[128]; };
        int main(void) { struct foo x; strcpy(x.app, "foo"); return 0; }

then it still dumps core but the backtrace is slightly more interesting:

(gdb) bt
#0  0x07f364ef in ?? ()
#1  0x0804964f in memcpy@@GLIBC_2.0 ()
#2  0x08048396 in main ()

If I generate a linker map looking for memcpy() I see this:

        .dynbss        0x0000000008049620       0x46 /cc/sysroot/usr/lib/../lib/crt1.o
                       0x0000000008049620                memcpy@@GLIBC_2.0

And crt1.o looks OK:

        $ file /cc/sysroot/usr/lib/crt1.o
        /cc/sysroot/usr/lib/crt1.o: ELF 32-bit LSB relocatable, Intel 80386,
          version 1 (SYSV), for GNU/Linux 2.6.18, not stripped

Looking at the rest of the linker map I don't see any references to any
objects or libraries that aren't either (a) in my compiler's directory,
like crtbegin.o etc., or (b) in the sysroot directories.  Sooo, I'm a
bit stumped.  Seems like something is mismatched somewhere...

Any idea where to look?