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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Paul Smith <paul@xxxxxxxxxxxxxxxxx> writes:

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

I agree with you: something is mismatched somewhere.  But I don't know
where.  The most obvious possibility is that you are somehow trying to
execute 64-bit code in 32-bit mode, but the dynamic linker is not
supposed to permit that to happen.  Your examples are odd because the
first one crashes before main, but the second one gets to main, even
though you haven't changed anything relevant.

If you want to solve this you are just going to have to dig into it.  I
predict that the problem will be very difficult to find and quite easy
to solve once found.

Ian


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


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux