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

[Paul Smith <paul at mad-scientist dot net>]

Anyone have any thoughts for me about where to start poking to try to
resolve (or at least get more details about) this issue?

Thanks!

On Thu, 2012-04-12 at 19:05 -0400, Paul Smith wrote:
> 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?
>