Paul Smith <paul@xxxxxxxxxxxxxxxxx> writes:
> 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.
It's a plausible argument but in fact there wouldn't be any such
initialization code before main is invoked in either case.
> I'm not really clear on what the different crt*.o files do or contain.
Code to run global constructors (if any), call main, and call exit if
main returns.
> 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?
Those are not normally found in crt1.o but it is of course possible that
they exist on your system.
> 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?
No, that is normal.
> 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?
I think that should theoretically work.
Ian
