Re: [PATCH] m32r: set CHECKFLAGS properly

Hirokazu Takata
2005-09-28T10:04:20Z

From: Al Viro <viro@ftp.linux.org.uk>
Date: Wed, 28 Sep 2005 01:18:40 +0100
> 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.

In the top Makefile, CHECKFLAGS is defined as follows:
CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ $(CF)

Can I use CF for user specific CHECKFLAGS ?
What do you think about we specify it manyally for a biendian target?

ex. m32r
sparse check for biendian target
$ make ARCH=m32r CF=-D__BIG_ENDIAN__=1 C=1 ... for big-endian
$ make ARCH=m32r CF=-D__LITTLE__=1 C=1 ... for little-endian

arch/m32r/Makefile:
CHECKFLAGS += -D__m32r__

> > 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.

I understand what you said.
I think having -D__BIG_ENDIAN__ is one of the realistic solutions,
because it seems that there is no good solution about this problem
as other people said in this ML-thread.

> 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.

IMHO, I think it is for convinience of building userland programs.
For example, in case of building programs (like Debian/GNU Linux
packages), it is useful that we can simply use a compiler without
not only modifying any source/Makefile but also specifing any
target-specific options of the compiler.

> 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?

I have no idea...

> 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...

I think so, too.
I hope we can do check both of target endianness intentionally.

-- Takata