The declaration.exp testcases rely on kernel module function probe points that don't exist in modern kernels. It would be better to rewrite these as user space tests, so the testsuite controls all inputs. Running /home/mark/src/systemtap/testsuite/systemtap.base/declaration.exp ... running stap -v -p4 -e probe\ module(\"libata\").function(\"ata_qc_issue\")\ \{\ print(\$qc->\$scsicmd->\$device->\$host->\$host_no)\ \}; Pass 1: parsed user script and 60 library script(s) using 19364virt/11576res/2096shr kb, in 120usr/10sys/130real ms. semantic error: no match while resolving probe point module("libata").function("ata_qc_issue") Pass 2: analyzed script: 0 probe(s), 0 function(s), 0 embed(s), 0 global(s) using 136912virt/12392res/2488shr kb, in 20usr/60sys/88real ms. Pass 2: analysis failed. Try again with another '--vp 01' option. PASS: empty-struct resolve-fail compilation failed correctly running stap -v -p4 -e probe\ module(\"scsi_mod\").function(\"scsi_request_fn\")\ \{print(\$q)\} probe\ module(\"libata\").function(\"ata_qc_issue\")\ \{\ print(\$qc->\$scsicmd->\$device->\$host->\$host_no)\ \}; Pass 1: parsed user script and 60 library script(s) using 19364virt/11576res/2096shr kb, in 120usr/10sys/140real ms. semantic error: no match while resolving probe point module("scsi_mod").function("scsi_request_fn") Pass 2: analyzed script: 0 probe(s), 0 function(s), 0 embed(s), 0 global(s) using 136912virt/12388res/2488shr kb, in 20usr/70sys/91real ms. Pass 2: analysis failed. Try again with another '--vp 01' option. FAIL: empty-struct resolve-pass compilation failed
This seems to be testing that one module can implicitly provide a struct declaration for a probe in some other module. IIRC, we decided against this "global type" behavior, opting instead to go with explicit @casts where necessary...
For now I XFAILed this test. But maybe it should be removed completely?
I'm thinking it should be removed. If we want to test that one module can implicitly provide a struct declaration for a probe in some other module, the safest way might be to write/compile/install a couple of custom kernel modules. But, that seems like overkill for a situation that '@cast' is designed to solve.
(In reply to comment #3) > I'm thinking it should be removed. OK, I removed the test completely.