Re: Checker support refinements, bugfixes, test cases

[Ken Raeburn <raeburn at cygnus dot com>]

> Looks pretty reasonable to me.  Did you ever get any feedback from Tristan?

Not recently, though we talked about some of it a while back.  We were
in agreement on checking static storage.  For the rest, well, he's
working on the Checker package itself, which uses a more coarse
approach.  Command-line options to instrument code and rename
functions, and system-library wrapper routines theoretically cause the
entire program to be instrumented.  So, as I recall, he wasn't
especially interested in the fine-grained control, but understood that
others might be.

> Presumably the BLKmode stuff doesn't actually pass a BLKmode value as an
> argument to emit_library_call, you just need address and length info right?

Right.

> How does the testsuite work?  Don't you need library support for it to
> function correctly?  Or is the checker support code totally self-contained
> within the compiler and libgcc.a?

That's what's in driver.c.  A really simple and inefficient set of
support routines, adequate for testing but not for production use.

> If checker relies on special library support, then we'll need some way to 
> indicate what systems have such library support to avoid running the testsuite
> on unsupported targets.

There is some machine-dependent stuff (e.g., builtin_saveregs), but
the test cases aren't exercising any of that yet.  They should,
eventually.  Checking of arguments and return values in general needs
better testing.

> It might be interesting to be able to control checking of stuff in the static
> store.  Then again, it might not :-)  I don't think we should hold up the patch
> for something like that.

Shall I check it in then?

Ken