Comparing a pointer against a literal without an explicit cast is not supported
by the C parser.

JIRA: VER-429

This has no effect on the code, but makes this value visible as a named
constant in Isabelle when importing C sources. It avoids us having to reference
120 as a magic number in numerous proofs.

This commit adds a two new output targets for the bitfield generator,
--autocorres-defs and --autocorres-proofs. These produce, respectively,
abstract definitions of the generated C functions suitable for use in
AutoCorres proofs and WP/simp lemmas suitable for use within AutoCorres proofs
of functions that call the generated C functions. Existing behaviour and
functionality should be unaffected.

Stdout is not suitable as an output target for these things.

Having the padding types as INT_MAX + 1 means C++ compilers will end up using
a signed 64 bit integer, as that is the only type that can have a value that
large, as well as the negative values our enums typically contain

The bitfield generator constructs tags as enums. The compiler is free to back
these by any type big enough to cover the enum. The generator emits code that
uses these tag values in mask and shift operations where the target type is
typically a uint32_t. As a result, it can produce code involving undefined
shifts like:

 (seL4_CapData_Badge & 0x1) << 31

This commit casts the tag value to the unsigned target type before masking to
ensure everything is done on an appropriate sized unsigned type.

JIRA: SELFOUR-193

The bitfield generator uses the macros CONST and PURE which, for libsel4, are
defined in macros.h.

trivial: Print domain values as unsigned integers in user errors.

Domains are unnecessarily treated explicitly as 8-bit values within boot info.
Though there are existing proof constraints that limit the maximum domain value
to 8 bits, most of the code would permit domain values up to 32 bits. The
maximum value is unnecessarily constrained in boot info, a restriction which
this commit removes.

Closes VER-341

With the comparison preceding this being done on unsigned integers, this avoids
confusing error messages like '-2147482648 >= 1'.

Implements two trivial functions that were present for IA32, but not included
in the corresponding ARM header.

Closes SELFOUR-226

Does not affect verification.

Derive a new IPC buffer cap when inserting into the initial threads TCB to remove mapping information

For any other thread setting the IPC buffer via TCB_Configure will result
in a derived capability being installed that does not have mapping information.
This leads to a expected behaviour that setting a new IPC buffer (even if it is
the same as the current one), will not perform an unmapping.

Remove trailing whitespace, and align comments.

Odroid XU3 support

The gic400 used on the Exynos5 platforms is a little different from
the pl390, and needs a few small changes.

The XU3 uses a 5422 which for seL4's purposes is almost the same as
the Odroid XU's 5410.  Define a new PLAT_EXYNOS54XX to cover both.

Keep PLAT_EXYNOS5410 and ...5422 for the few places (not in the
kernel) where the difference matters.

syscall stub generator: change CapDataType into a generic BitFieldType for using bitfield generated types in generated invocations

Prior to this commit there was an unfortunate disagreement between the seL4
project build system and the kernel's Makefile. V=3 was interpreted as maximum
verbosity by the project build system and minimum verbosity by the kernel's
Makefile. This commit makes V=3 the maximum verbosity for both.

JIRA: VER-159

Initialise the 'ret' struct from a constant zero struct to ensure that no
uninitialised data is returned. Returning uninitialized data creates headaches
for binary verification.

This function is inlined in builds I have looked at, and the 'ret' struct is
never built, so this change has zero impact on the binary.

Set default MAX_NUM_BOOTINFO_DEVICE_REGIONS to a value that will fit into the initial boot info frame

The c-parser can now parse these functions, but it does it by
discarding the inline ASM block, creating a misleading and likely
malformed function body. It is better to not translate these
with a DONT_TRANSLATE comment.

This change has been made for the current verification platform
only, and should probably be extended to any other verification
targets as necessary.