Architecture names follow L4V_ARCH-style naming conventions ('ARM', 'FAKE64').
However, the standalone parser does not make use of the L4V_ARCH environment
variable.
The standalone-parser Makefile builds all architectures at once, producing
binaries at 'ARM/c-parser', 'FAKE64/c-parser', and similarly for the tokenizer.
There are also wrapper scripts 'c-parser' and 'tokenizer' in the
standalone-parser directory, which take an architecture on the command line.
The make_munge.sh script calls the appropriate binary parser directly.
This is apparently valid C:
enum {
One,
Two = One + 1,
};
It's easy to support this by using the partially modified enum
environment in evaluation of the following right hand sides.
Give the standalone c-parser the facility to dump out its internal AST. Only
half finished, I got bored writing serialisers for the many syntax datatypes.
There has been some discussion about how to check whether an seL4 change
impacts verification. My thought was that the obvious thing to check is the
C-parser's AST. If this is unchanged, then further analyses must be unchanged.
Specification of file to emit to is via command-line switch. Take the
opportunity to make comand-line processing be done via GetOpt library.
JIRA VER-473
- the symbol table constant had a hard map to word32 instead of the addr
alias
- when cast to integers, the parser believed pointers gave rise to 32
bit values. This latter required the TargetNumbers signature to get a
smidge wider, with a new ptr_t entry where the intptr type gets
listed.
This ignores issues that would need getting right in a real x64
specification (signedness of char, endianness, perhaps others), but can
be used as a test vehicle.
The base file that needs to move is Vanilla32_typinfo, which is what
this commit does. Various descendants may need splitting into
architecture-specific and general parts.
Depends on configuration variable (as per example in
testfiles/jira473.thy), "munge_info_fname". If this is not set, then no
export occurs. File written is with respect to directory Isabelle is
started in, which may not be ideal.
Format in the file is a series of lines:
function_name::var_name -> munged_name
If the variable is global, then function_name is blank.
JIRA VER-473
At the moment, if there is a specification and DONT_TRANSLATE, the
automatic proofs only work if the specification is that no globals are
modified.
Work on JIRA VER-464
In particular, if the only specification attached is the MODIFIES line,
then the automatic machinery will cope with proving the modifies result.
So, now rule out those with DONT_TRANSLATE and at least one fnspec.
Why this is suddenly a problem now, when there hasn't been a change to
this file in years is completely unclear. Nonetheless, I need a green
build.
The error was:
*** Duplicate fact declaration "dc_20081211.dc_20081211.test_modifies"
vs. "dc_20081211.dc_20081211.test_modifies" (line 42 of
"~/repos/v/l4v/tools/c-parser/testfiles/dc_20081211.thy")
*** At command "lemma" (line 42 of
"~/repos/v/l4v/tools/c-parser/testfiles/dc_20081211.thy")
Green build except for:
CParserTest (WTF Duplicate fact declaration "dc_20081211.dc_20081211.test_modifies")
AutoCorresSEL4 (waiting on result)
There is still a carefully managed sorry in Schedule_R, waiting on the C
parser FNSPEC+DONT_TRANSLATE fix.
When isa_type_to_typ is called from a theory other than the one the type was
declared in, it would pick the wrong fully qualified name. Now the function
should be robust against a) yet undeclared types (for record decls), b)
existing types in same theory (normal case), and c) existing struct types
from other theories (e.g. from autocorres).
The tactic used to establish that a large struct is a umm type doesn't
cope with large number of fields (>= 108 in this case). The translation
used to create a struct containing fields corresponding to all of the
program's addressed globals, but this is actually unnecessary now that
the translation handles these via the locale parameter "symbol_table".
So, the fix is to simply not generate that struct and so not to attempt
to prove the umm-type property of it. Grepping for adglobs in the
verification proof reveals that it isn't used anywhere (as one would
hope), so I'm reasonably confident that this shouldn't cause any wider
regressions. (Fingers crossed.)
Even if the value given to the constant inside the enum was "just"
2147483647, the loop that processed enumeration declarations would then
add 1 to that number, and in mlton, this would cause an Overflow
exception. By using IntInf in this position, mlton does the right
thing, and Poly/ML's behaviour is completely unchanged.
Japheth's recent change (6f7c660cb) to error-reporting for the latter
broke the former. Refactor code so that old and new code can coexist.
Would just use Japheth's code in the purely SML version too, but it uses
Isabelle/ML libraries that I can't be bothered to recreate in SML.
The handling of local static variables is now part of a general
improvement in the handling of all the "munging" that the parser does.
*Munging* is the process of renaming variables so that Isabelle can cope
with them. There are at least three different forms of munging at the
moment:
- static locals get munged so that multiple static locals (which have to
be treated as globals) can co-exist with the same source name.
- local variables of the same source name but different types have to be
able to co-exist
- variables with legitimate C names but illegal Isabelle names have to
be allowed
The new structure MString implements an opaque version of string
designed to make it clear to the typechecker that certain strings are
"munged".
They are now treated as globals with a specially munged name, derived
from the given name and the name of the function where they occur. The
function NameGeneration.mk_localstatic generates the "munged" name.
As with other globals, initialisation is not handled very well (i.e., at
the moment the initialisation is completely ignored).
Close JIRA VER-439
In particular, don't reveal the internal references used during
yacc-ing to the user-level. Instead, add a referentially transparent
repair of the AST after its been parsed.
JIRA VER-432
As per example, syntax is
declare [[cpp_path="path to file"]]
If the empty string is used as the value, then no preprocessor will be
called.
The standalone parser has also been adjusted so that you can it with
--cpp=path
or
--nocpp
options.
Closes JIRA issue VER-337
This change means that we can't silently catch proof failures, which the
current code does. We theoretically know the outcome of the proof in
advance, so this should be safe...
Allows vcg_tag ("apply vcg") to process functions with "cchaos" in them.
This was an attempt to solve the problem that the C parser's modifies
proofs currently fail for functions containing "cchaos".
The problem, however, actually seems to be that the C parser fails to
realise that incorrectly owned _read_ variables (which are updated using
"cchaos" before being read) need to be in the "modifies" set of
a function. Currently, the C parser misses these modifications, and the
proof of the incorrect modifies set (rightly) fails.
The functor is gone, and instead StaticFun exports two more general
operators, one for defining a partial map by a tree, and one for
extracting the theorems from an existing partial map definition.
The extraction process uses simplification in a more conservative
manner than before, and is guaranteed to produce exactly the
expected theorems.
In detail:
- add a general user-specified exception to c_exntype
(for use in tools like Substitute)
- wrap calls to 'halt' in Guard {}, making it clearer that
halt is never called, simplifying asmrefine
- repair halt changes in crefine
- avoid use of some suspicious 'modifies' properties in crefine
which were generated by the parser for functions where inline
ASM blocks have been elided, and which may be inaccurate.
This suggests there are bad things happening in the hoare package's
code for parsing (as the commented out code is simply a lemma
statement followed by oops).
CParser not finished yet, though: getting errors in cparser_test about linear
theory updates at end of thy.
Found more instances where we should be using Local_Theory.exit_global, but
might be besides the point (didn't help). Also might be overshooting the goal.
Michael Norrish
Matthew Brecknell
Thomas Sewell
Alejandro Gomez-Londono
Japheth Lim
Joel Beeren
Gerwin Klein
Sophie Taylor
Matthew Brecknell
Ramana Kumar
Daniel Matichuk
Rafal Kolanski
David Greenaway
Lars Noschinski