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?
>
