[readding people to Cc assuming that's ok]
Hello Luc,
On Mon, Sep 04, 2017 at 10:36:47PM +0200, Luc Van Oostenryck wrote:
> On Mon, Sep 4, 2017 at 10:57 AM, Uwe Kleine-König <uwe@xxxxxxxxxxxxxxxxx> wrote:
> > On 09/03/2017 11:14 PM, Luc Van Oostenryck wrote:
> >> On Fri, Sep 1, 2017 at 9:02 AM, Josh Triplett <josh@xxxxxxxxxxxxxxxx> wrote:
> >>> Related to that: while it would mean we couldn't necessarily just rely
> >>> entirely on GCC's definitions for a target platform, I think in an ideal
> >>> world we could have a sparse binary that understood *all* target
> >>> platforms at once, such that you could ask Sparse on x86_64 to "compile"
> >>> as though targeting any arbitrary architecture. That would also have the
> >>> major advantage of making it easy to run the Sparse testsuite for
> >>> *every* target architecture without needing compilers for every such
> >>> architecture.
> >>
> >> I really think that the testsuite should not depend on system or library
> >> header.
> >
> > Assuming it's intended that sparse should be able to check userspace
> > programs, I don't agree here.
>
> I understand this.
> I'll explain a bit better my point of view.
> First, I make a distinction between 'sparse core functionalities' and
> general usage.
> I was talking about this core usage and the testsuite is currently for this core
> usage too.
and while it's ok to test the core stuff and not wanting the system
includes to interfere, there should also be tests that check "ordinary"
userspace programs which naturally depend on the system headers.
> Asking for the testsuite to not depends on system or library header is exactly
> the same as GCC people asking bug reports to be done on pre-processed file
> (so that they focus on the core problem and not some problem with an header).
> This, of course, doesn't mean that GCC should only be used on standalone
> source files nor that GCC shouldn't be tested on real code, using
> system headers.
> It's just something different.
>
> So to answer to your objection: yes, you're right but it should be done in some
> specific tests, not the core ones.
ah, we agree. Fine.
> Secondly, about "intended to check userspace programs":
> It's clear that sparse's main use is for the kernel, but it's also
> clear that it can
> and is used on other (userspace) projects.
> However, as you have seen yourself, you can't use sparse as is and expect
> to work on any environment, on any architecture. Even for the kernel it doesn't:
> each architecture has to specify a few flags (like -m32/-m64) and a few defines
> (-D__arm__, ...). For userspace, cgcc can do a part of this job for you.
>
> Josh proposal to have what I called a 'universal' sparse, won't solve this,
> on the contrary.
> Compilers eschew part of this problem by having to configure the build
>
> I'm all in favor to move cgcc logic to sparse and/or it's build system so that
> *for a native build* it can be used as-is in most cases.
> This would solve your problem, I think.
>
> BTW, sorry I didn't follow last week but is your problem solved now?
No, it's not solved. But given that it is somehow known that sparse
(without cgcc) fails to work well on userspace stuff, I think the
following would be fine for the Debian side:
a) let horst use cgcc instead of sparse
b) downgrade bug to important or even normal pointing out that cgcc
should be used for userspace programs
For sparse it would be cool to:
c) drop the #weak_define of __amd64__ to make this "problem" more
apparent. (Assuming this doesn't break e.g. a kernel build.)
d) fix the test suite, at least mark the tests that are expected to
fail on !x86 as such to make $(make check) succeed. (Otherwise I'd
have to disable or ignore the testsuite which isn't that great.)
Best regards
Uwe
Attachment:
signature.asc
Description: PGP signature
