[cfe-dev] architecture endianness and preprocessor defines
Eric Christopher
echristo at apple.com
Wed May 7 09:30:25 PDT 2008
I'll apologize that you've had such a hard time with this, but I've also
never seen an email from you asking about these things. That said,
many things you mentioned are just wrong.
> One of the additional hassles with GCC is that its "multilib" feature
> doesn't consistently build the C runtime environment, i.e. crtstuff.c,
> for both big- and little-endian modes. This is why there are all
> those GCC target triples that look like "armeb-netbsd-elf" and
> "mipsel-
> wrs-vxworks" and "armle-linux-gnu" in the configure script. Notice
> that the suffixes aren't used consistently across operating system
> platforms?
>
This is true, however, the suffixes are usually created by the people
doing the work for the platform for the specific target triple...
> The suffix on the architecture name ends up getting translated into
> the endianness of the C runtime environment modules used by the linker
> (except when -nostdlib is used... sigh). If it weren't for this,
> you'd be able to build GCC for ARM or MIPS or whatever, without adding
> that suffix to the architecture part of the triple, and the -mbig-
> endian and -mlittle-endian switches would select the proper C runtime
> environment. Sadly, that doesn't happen like it should.
Interestingly enough you're absolutely wrong here. The suffixes merely
allow you to select a different default. They are an alias. Nothing
else.
The switches allow you, if the target has support for it, to change
mode.
Many of the OS targets aren't bi-endian and don't support changing.
For the last 5 years at least almost all of the preprocessor builtins
are
done using a standard method that will have them in 3 different
canonical forms, 2 of which you mentioned in your mail for big endian.
This is also mostly a complaint about configure and not gcc and mostly
not applicable to cfe either (though it may be a general llvm
discussion).
If you want to respond I suggest we take this discussion to private
email or the llvm list (or the gcc list if you want to change how gcc
does
it).
-eric
More information about the cfe-dev
mailing list