| 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859 |
- 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
|
