Note that this page is descriptive for probe consumers, not prescriptive for probe producers. So it’s describing what sdt.h currently does, and that “may be extended” line is just leaving the door open for future possibilities, like integer vector registers. I expect it will always stay at the level of things that the assember understands.
Generally we expect to see register and memory[+offset] operands, but this note is pointing out that you may see integer literals too, and the complication that powerpc presents with that.
No, assembler doesn’t really know anything about strings. Sometimes CPUs have instructions meant for dealing with strings, like the x86 REP prefix, but operands are still just singular values, like pointers, integers, and floating point.
Concepts like strings can be represented in debuginfo, but sdt.h is explicitly meant to operate at a lower level than that, so it can be used in production even on fully-stripped binaries.
So it’s left to the probe author to document elsewhere what the probe arguments actually mean, and the semantics of how to interpret them. You could pass a C char* string as a simple pointer argument, and a “fat” pointer like Rust &str would need two probe arguments, pointer and length. You could probably destructure that &str automatically in your plugin, but it might be confusing for using a probe with multiple arguments if the arg indexes don’t quite line up to what was written.
