60 lines
2.7 KiB
Plaintext
60 lines
2.7 KiB
Plaintext
KSelfTest arm64/signal/
|
|
=======================
|
|
|
|
Signals Tests
|
|
+++++++++++++
|
|
|
|
- Tests are built around a common main compilation unit: such shared main
|
|
enforces a standard sequence of operations needed to perform a single
|
|
signal-test (setup/trigger/run/result/cleanup)
|
|
|
|
- The above mentioned ops are configurable on a test-by-test basis: each test
|
|
is described (and configured) using the descriptor signals.h::struct tdescr
|
|
|
|
- Each signal testcase is compiled into its own executable: a separate
|
|
executable is used for each test since many tests complete successfully
|
|
by receiving some kind of fatal signal from the Kernel, so it's safer
|
|
to run each test unit in its own standalone process, so as to start each
|
|
test from a clean slate.
|
|
|
|
- New tests can be simply defined in testcases/ dir providing a proper struct
|
|
tdescr overriding all the defaults we wish to change (as of now providing a
|
|
custom run method is mandatory though)
|
|
|
|
- Signals' test-cases hereafter defined belong currently to two
|
|
principal families:
|
|
|
|
- 'mangle_' tests: a real signal (SIGUSR1) is raised and used as a trigger
|
|
and then the test case code modifies the signal frame from inside the
|
|
signal handler itself.
|
|
|
|
- 'fake_sigreturn_' tests: a brand new custom artificial sigframe structure
|
|
is placed on the stack and a sigreturn syscall is called to simulate a
|
|
real signal return. This kind of tests does not use a trigger usually and
|
|
they are just fired using some simple included assembly trampoline code.
|
|
|
|
- Most of these tests are successfully passing if the process gets killed by
|
|
some fatal signal: usually SIGSEGV or SIGBUS. Since while writing this
|
|
kind of tests it is extremely easy in fact to end-up injecting other
|
|
unrelated SEGV bugs in the testcases, it becomes extremely tricky to
|
|
be really sure that the tests are really addressing what they are meant
|
|
to address and they are not instead falling apart due to unplanned bugs
|
|
in the test code.
|
|
In order to alleviate the misery of the life of such test-developer, a few
|
|
helpers are provided:
|
|
|
|
- a couple of ASSERT_BAD/GOOD_CONTEXT() macros to easily parse a ucontext_t
|
|
and verify if it is indeed GOOD or BAD (depending on what we were
|
|
expecting), using the same logic/perspective as in the arm64 Kernel signals
|
|
routines.
|
|
|
|
- a sanity mechanism to be used in 'fake_sigreturn_'-alike tests: enabled by
|
|
default it takes care to verify that the test-execution had at least
|
|
successfully progressed up to the stage of triggering the fake sigreturn
|
|
call.
|
|
|
|
In both cases test results are expected in terms of:
|
|
- some fatal signal sent by the Kernel to the test process
|
|
or
|
|
- analyzing some final regs state
|