FAIL: sdt_misc asm (0) asm
spawn /usr/local/install/systemtap/bin/stap -c /usr/local/build/systemtap-obj/te
WARNING: cannot find module /usr/local/build/systemtap-obj/testsuite/sdt_asm.x d
ebuginfo: No DWARF information found
semantic error: while resolving probe point: identifier 'process' at /home/mark/
source: probe process(@1).mark("a")
semantic error: no match
This is caused by:
Author: Wade Farnsworth <firstname.lastname@example.org>
Date: Wed Mar 28 07:46:16 2012 -0700
PR13475: Fix ARM SDT_V3 operand parsing
* Include regular expressions to parse ARM operands
* Add ARM register data
* Allow for whitespace in ARM operands containing 's
Signed-off-by: Wade Farnsworth <email@example.com>
Some more analysis:
(In reply to comment #1)
> Some more analysis:
> For compiler-generated code, each argument will be of the form N@OP.
> For hand-written assembly, or for inline assembly in C or C++, the initial
> N@ may be missing. If N is present, it describes the size of the argument.
> [...] If N is omitted, the argument size is the natural size of the operand;
> usually this is the size of the register or the word size of the machine.
> In this case, the signedness is ambiguous.
Ugh, I didn't realize SDTv3 exempted assembly from N@OP, but indeed that's how it plays out -- _SDT_ARGFMT is only defined in the !__ASSEMBLY__ case. That certainly complicates things... :(
One possible solution is to detect the absence of @'s in the sdt-v3 operand string, and infer that this was an assembler invocation. Then back down to ' ' based tokenization (and make the spaced-out arm operand unusable).
(In reply to comment #3)
> One possible solution is to detect the absence of @'s in the sdt-v3 operand
> string, and infer that this was an assembler invocation. Then back down to ' '
> based tokenization (and make the spaced-out arm operand unusable).