Re: [PATCH] m32r: set CHECKFLAGS properly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 27, 2005 at 08:00:03AM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 27 Sep 2005, Hirokazu Takata wrote:
> > 
> > Now, the endianness is to be determined by a (cross)compiler:
> > - For the big-endian, a compiler (m32r-linux-gcc or m32r-linux-gnu-gcc)
> >   provides a predefined macro __BIG_ENDIAN__.
> > - For little-endian, a compiler (m32rle-linux-gcc or m32rle-linux-gnu-gcc)
> >   provides a predefined macro __LITTLE_ENDIAN__.
> 
> Hmm.. You need to tell sparse _some_ way which one you use, since sparse 
> won't do it.
> 
> Picking one at random is fine, of course. It doesn't even have to match 
> the one you'll compile with, although that means that sparse will 
> obviously be testing a different configuration than the one you'd actually 
> compile.
> 
> So I think having -D__BIG_ENDIAN__ in the sparse flags is better than not
> having anything at all (since otherwise it won't be able to check
> anything). And having something that matches the compiler would be better
> still.

Really interesting question is why do we need two toolchains at all.
Note that little-endian m32r gcc at least appears to understand
-mbe/-mbig-endian and binutils handles both endianness just fine.

Does that really work and is there any reason why big-endian one
could not handle -mle the same way with minimal changes?  IOW, do
they have to differ in anything except the default target endianness?

Note that dependencies on "host endianness == target endianness" are
practically guaranteed to cause bugs in cross-compiler, so any of
those would very likely to be a bug in need of fixing anyway...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux