Hi all; no responses to this so far. Is it just too old a release to
bother with, and/or does no one have any thoughts about it or ideas of
where to look? Cheers!
On Tue, 2012-04-17 at 16:42 -0400, Paul Smith wrote:
> 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?
