Re: sparse test failures on ppc32le (and other not so common archs)

From: Christopher Li <sparse@chrisli.org>
To: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: "Josh Triplett" <josh@joshtriplett.org>,
	"Uwe Kleine-König" <uwe@kleine-koenig.org>,
	"Ramsay Jones" <ramsay@ramsayjones.plus.com>,
	Linux-Sparse <linux-sparse@vger.kernel.org>,
	873508@bugs.debian.org, "Antoine Beaupre" <anarcat@debian.org>
Subject: Re: sparse test failures on ppc32le (and other not so common archs)
Date: Mon, 4 Sep 2017 14:00:56 -0400	[thread overview]
Message-ID: <CANeU7Q=fBkQAWfB8sWW0=ZWC8CJV83w8Bo_iHeaRBHKc8vLB-Q@mail.gmail.com> (raw)
In-Reply-To: <CAMHZB6En=BeF_6NBfEDr26hdP5rmTt+A4p5Y3Cn=nEzZDaTz9w@mail.gmail.com>

On Sun, Sep 3, 2017 at 5:14 PM, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
>
> I really think that the testsuite should not depend on system or library
> header.

I think that is a good point. We can start cleaning up the system header
file dependency in the existing test suite. See how it goes.

>
> Otherwise, I'm not at all opposed to sparse being universal but I would like
> to note that things can become very quickly very very messy.
> For example, for the current problem here I understood that it was
> at least partially based on the lack of a definition of _CALL_ELF
> but do we need to define it to 1 or to 2, in other words, do we need
> to support the ELFv1 ABI or the ELFv2? GCC has some flags for this
> (-mabi=elfv[12]) but what default value do we want? ELFv1 is the default

I think we can just sparse default to as late as the latest release
version of gcc.

> for big-endian platform and ELFv2 for little-endian platform, so yes,
> we need a flag for the endianness but which endianness we want as default?

I am tempting to make the endianness the same as the host gcc by default.
Then it can be overwrite by architecture flags.

>
> Things become even more fun when taking in account the difference
> between GCC version. Do we want to be universal there too (and thus
> have some flags for to specify which gcc's version we want to mimick)?
> What about other compilers?

I purpose just sync to the latest gcc version (or a late enough version
we can agree on. e.g. the one that supported by kernel compile.) Sparse
current try to sync to the latest gcc attributes already.

> I think that part of the needed info can be auto-extracted from GCC
> when doing a native build. Using some sort of spec file or a .sparserc

Is there a way to do auto-extract? That would be a good starting point.

> I also note that currently, sparse is already largely universal *because*
> it *doesn't* need those platform details (or only the very minimal: word size).

Sparse is not universal, it just support a very small sub set of the C
source file that haven't expose to those platform detail macros. Adding
those architecture macro support will not make it any less universal.
Might slow things down, that is some thing we need to watch out for.

Chris