On Mon, 2012-04-23 at 10:56 -0700, Ian Lance Taylor wrote:
> > 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.
It seems to me that there was a relevant change: the first example used
a struct initializer:
int main(void) { struct foo x = {0}; return 0; }
while the second one invoked strcpy():
int main(void) { struct foo x; strcpy(x.app, "foo"); return 0; }
That means that in the first example the compiler needs to set up code
to initialize the struct before main is invoked, while in the second
example it does the strcpy() after main is invoked. So the difference
in behavior (crash before main vs. in main) makes some kind of sense.
I'm not really clear on what the different crt*.o files do or contain.
It appears, from my linker map, that crt1.o contains specially-tuned
versions of some basic functions like memcpy() etc. and that these are
used not just when you call memcpy() but also by the compiler to do
things like initialize data structures... maybe?
Maybe there's some kind of mismatch between the compiler and the crt1.o
in the sysroot: I see that the sysroot appears to contain crt1.o,
crtn.o, and crti.o while the compiler appears to contain lots of other
crt*.o files like crtbegin.o, crtend.o, etc. They do all appear to have
the right bit-ness though (32 vs. 64).
Is that a cause for concern?
Let me ask a more general question: what I'm trying to do is create a
single "generic" compiler toolchain (gcc, binutils, gdb, flex, bison,
m4, etc.) which will run on most any Intel GNU/Linux system (I'm
compiling with --host as Red Hat EL 4 32bit and want 32bit apps in the
toolchain) and which, given one of a number of different Intel GNU/Linux
target sysroots, will be able to compile both 32bit and 64bit code for
those targets.
So my question is, is that a use-case that you feel is supported by GCC
in general and, barring bugs or my mistakes, should theoretically work?
Or have I missed some fundamental fact that makes my goal not
achievable?
