Clarify choice of illegal instruction encoding

The unprivileged spec says the following:

We consider it a feature that any length of instruction containing all
zero bits is not legal, as this quickly traps erroneous jumps into
zeroed memory regions. Similarly, we also reserve the instruction
encoding containing all ones to be an illegal instruction, to catch the
other common pattern observed with unprogrammed non-volatile memory
devices, disconnected memory buses, or broken memory devices.

Software can rely on a naturally aligned 32-bit word containing zero to
act as an illegal instruction on all RISC-V implementations, to be used
by software where an illegal instruction is explicitly desired. Defining
a corresponding known illegal value for all ones is more difficult due
to the variable-length encoding. Software cannot generally use the
illegal value of ILEN bits of all 1s, as software might not know ILEN
for the eventual target machine (e.g., if software is compiled into a
standard binary library used by many different machines). Defining a
32-bit word of all ones as illegal was also considered, as all machines
must support a 32-bit instruction size, but this requires the
instruction-fetch unit on machines with ILEN>32 report an illegal
instruction exception rather than access fault when such an instruction
borders a protection boundary, complicating variable-instruction-length
fetch and decode.

Signed-off-by: Ahmed Charles <acharles@outlook.com>
Change-Id: I86c1b165efaaec0cb4c942da37f91903d737edb6
1 file changed
tree: cd9b6600a8e7438da69f9e5955fe6c5931682b93
  1. .github/
  2. apps/
  3. docs/
  4. integrations/
  5. libsel4testsupport/
  6. LICENSES/
  7. .gitignore
  8. .licenseignore
  9. CMakeLists.txt
  10. domain_schedule.c
  11. easy-settings.cmake
  12. LICENSE.md
  13. PREUPLOAD.cfg
  14. README.md
  15. settings.cmake
README.md

sel4test

Library for creating and running tests for seL4.

Setup

See the Getting Started page for instructions for installing required Host dependencies and how to checkout, build and run the tests in seL4test (this project).

Usage

Small unit tests can be defined anywhere, such as libraries outside of sel4test or in sel4test-driver. Larger tests that do things like creating processes need to be declared inside sel4test-tests.

Unit tests

To define a small unit test in a library outside of sel4test or in sel4test-driver:

  1. Declare libsel4test as a dependency for your library and include <sel4test/test.h>. You may also find the functions in <sel4test/testutil.h> handy.
  2. Write your tests. Then, for each test you want to run, call one of the macros that define a test, such as the DEFINE_TEST macro. They are declared here.
  3. Add your library as dependency to libsel4testsupport. Add a call to any function in your test file to testreporter.c in dummy_func(). If you have multiple test files, then you need to call one function for each test file.

For an example, take a look at libsel4serialserver/src/test.c in sel4_libs.

Assumptions

Currently unit tests are assumed to be running sequentially, standalone (i.e. not multi-threaded). Some tests rely on being the highest priority running thread in the system.

Other tests

To define a larger test in sel4test-tests:

  1. Place your test in apps/sel4test-tests/src/tests.
  2. Include <../helpers.h>.
  3. Write your tests. Then, for each test you want to run, call one of the macros that define a test, such as the DEFINE_TEST macro. They are declared here.

For an example, take a look at trivial.c in sel4test.