1*4882a593SmuzhiyunKSelfTest arm64/signal/ 2*4882a593Smuzhiyun======================= 3*4882a593Smuzhiyun 4*4882a593SmuzhiyunSignals Tests 5*4882a593Smuzhiyun+++++++++++++ 6*4882a593Smuzhiyun 7*4882a593Smuzhiyun- Tests are built around a common main compilation unit: such shared main 8*4882a593Smuzhiyun enforces a standard sequence of operations needed to perform a single 9*4882a593Smuzhiyun signal-test (setup/trigger/run/result/cleanup) 10*4882a593Smuzhiyun 11*4882a593Smuzhiyun- The above mentioned ops are configurable on a test-by-test basis: each test 12*4882a593Smuzhiyun is described (and configured) using the descriptor signals.h::struct tdescr 13*4882a593Smuzhiyun 14*4882a593Smuzhiyun- Each signal testcase is compiled into its own executable: a separate 15*4882a593Smuzhiyun executable is used for each test since many tests complete successfully 16*4882a593Smuzhiyun by receiving some kind of fatal signal from the Kernel, so it's safer 17*4882a593Smuzhiyun to run each test unit in its own standalone process, so as to start each 18*4882a593Smuzhiyun test from a clean slate. 19*4882a593Smuzhiyun 20*4882a593Smuzhiyun- New tests can be simply defined in testcases/ dir providing a proper struct 21*4882a593Smuzhiyun tdescr overriding all the defaults we wish to change (as of now providing a 22*4882a593Smuzhiyun custom run method is mandatory though) 23*4882a593Smuzhiyun 24*4882a593Smuzhiyun- Signals' test-cases hereafter defined belong currently to two 25*4882a593Smuzhiyun principal families: 26*4882a593Smuzhiyun 27*4882a593Smuzhiyun - 'mangle_' tests: a real signal (SIGUSR1) is raised and used as a trigger 28*4882a593Smuzhiyun and then the test case code modifies the signal frame from inside the 29*4882a593Smuzhiyun signal handler itself. 30*4882a593Smuzhiyun 31*4882a593Smuzhiyun - 'fake_sigreturn_' tests: a brand new custom artificial sigframe structure 32*4882a593Smuzhiyun is placed on the stack and a sigreturn syscall is called to simulate a 33*4882a593Smuzhiyun real signal return. This kind of tests does not use a trigger usually and 34*4882a593Smuzhiyun they are just fired using some simple included assembly trampoline code. 35*4882a593Smuzhiyun 36*4882a593Smuzhiyun - Most of these tests are successfully passing if the process gets killed by 37*4882a593Smuzhiyun some fatal signal: usually SIGSEGV or SIGBUS. Since while writing this 38*4882a593Smuzhiyun kind of tests it is extremely easy in fact to end-up injecting other 39*4882a593Smuzhiyun unrelated SEGV bugs in the testcases, it becomes extremely tricky to 40*4882a593Smuzhiyun be really sure that the tests are really addressing what they are meant 41*4882a593Smuzhiyun to address and they are not instead falling apart due to unplanned bugs 42*4882a593Smuzhiyun in the test code. 43*4882a593Smuzhiyun In order to alleviate the misery of the life of such test-developer, a few 44*4882a593Smuzhiyun helpers are provided: 45*4882a593Smuzhiyun 46*4882a593Smuzhiyun - a couple of ASSERT_BAD/GOOD_CONTEXT() macros to easily parse a ucontext_t 47*4882a593Smuzhiyun and verify if it is indeed GOOD or BAD (depending on what we were 48*4882a593Smuzhiyun expecting), using the same logic/perspective as in the arm64 Kernel signals 49*4882a593Smuzhiyun routines. 50*4882a593Smuzhiyun 51*4882a593Smuzhiyun - a sanity mechanism to be used in 'fake_sigreturn_'-alike tests: enabled by 52*4882a593Smuzhiyun default it takes care to verify that the test-execution had at least 53*4882a593Smuzhiyun successfully progressed up to the stage of triggering the fake sigreturn 54*4882a593Smuzhiyun call. 55*4882a593Smuzhiyun 56*4882a593Smuzhiyun In both cases test results are expected in terms of: 57*4882a593Smuzhiyun - some fatal signal sent by the Kernel to the test process 58*4882a593Smuzhiyun or 59*4882a593Smuzhiyun - analyzing some final regs state 60