[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