Bug 17958 - Systemtap doesn't like variables with ~ in their name
Summary: Systemtap doesn't like variables with ~ in their name
Alias: None
Product: systemtap
Classification: Unclassified
Component: translator (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
Depends on:
Reported: 2015-02-11 15:29 UTC by Aram Hăvărneanu
Modified: 2015-04-09 20:31 UTC (History)
2 users (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Aram Hăvărneanu 2015-02-11 15:29:19 UTC
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.
Comment 1 Mark Wielaard 2015-04-09 12:50:29 UTC
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?
Comment 2 Mark Wielaard 2015-04-09 16:30:43 UTC
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).
Comment 3 Mark Wielaard 2015-04-09 16:31:11 UTC
(In reply to Mark Wielaard from comment #2)
> After fixing PR17958 and PR17959

Sorry, PR17957 and PR17959
Comment 4 Mark Wielaard 2015-04-09 20:31:44 UTC
commit e207d98fdd2ccb31e9abb4956f5814022892d17e
Author: Mark Wielaard <mjw@redhat.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.