On Mon, Aug 29, 2011 at 8:14 AM, Derek M Jones <derek@xxxxxxxxxxxx> wrote:
>
> Can people allay my concern that this work is not on the slippery
> slope leading to sparse becoming the recommended compiler for
> building the kernel?
That was never really a goal.
What *was* a goal for me a long time ago was to make sparse be a
"preprocessor" in front of gcc, because the standard C pre-processor
has always been weak and we've always abused it in nasty ways (look at
all the games we play with "sizeof" and "typeof" to make our
"kernel-C" have a kind of generic programming).
Having a semantically aware preprocessor would allow kernel-specific
type extensions (like the "__user" attribute we already use purely for
checking runs), and allow debug facilities like "trace accesses to
this variable" without having to have ugly and unreadable wrappers
etc.
But even that got put on the back-burner when gcc improved the
pre-processor performance. It used to be a separate phase, and quite
slow, and having a quick semantic analysis in front of cc1 that
replaced the gcc preprocessor wouldn't have been a big slow-down. But
with the new (well, no longer new) built-in pre-processor, a sparse
front-end would slow down kernel compiles noticeably.
The main reason I used to want to have a back-end was that without a
back-end you cannot really verify the front-end. You can read
"test-linearize" output all day long, you'll never really get very
far. Once you generate code, and can use the thing to actually compile
real programs, that gives you *way* more confidence that you're doing
things right.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
