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

[Ian Lance Taylor <iant@xxxxxxxxxx>]

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