Go generates synthetic names for unnamed return argument of the form ~rN and ~bN. The linker will take these symbols and happily generate DWARF for them using the same names, DWARF which will cause systemtap to:
/tmp/stap0HUzn4/stap_781fe1254d17c543f4a055e0fd334bdc_557047_src.c:15047:38: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘~’ token
static void function__dwarf_tvar_get_~r0_259 (struct context * __restrict__ c);
Notice the ~ in the function name.
I can see how this would fail and the fix is probably easy, but I hae some trouble creating a reproducer. Do you have a simple stap script and golang program that triggers this?
After fixing PR17958 and PR17959 I got a reproducer. Now basically anything using $$parms in a probe will trigger it. It probably didn't show up before those bugs were fixed because stap thought it couldn't resolve those variable locations (and so would just produce a "static" '?' value).
(In reply to Mark Wielaard from comment #2)
> After fixing PR17958 and PR17959
Sorry, PR17957 and PR17959
Author: Mark Wielaard <email@example.com>
Date: Thu Apr 9 22:17:21 2015 +0200
PR17958 escape DWARF names that aren't C identifier strings.
Some language compilers (golang) might output DWARF names that are not
valid C identifier strings. Provide a escaped_indentifier_string ()
function to turn those into valid C identifier strings so the generated
C code compiles cleanly.