[Bug translator/10299] mangle local variable names

[Bug translator/10299] mangle local variable names

[jistone at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=10299

--- Comment #3 from Josh Stone <jistone at redhat dot com> 2011-11-24 22:18:21 UTC ---
*** Bug 13434 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug translator/10299] mangle local variable names

[bmr at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=10299

Bryn M. Reeves <bmr at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bmr at redhat dot com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug translator/10299] mangle local variable names

[smakarov at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=10299

Serguei Makarov <smakarov at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smakarov at redhat dot com

--- Comment #4 from Serguei Makarov <smakarov at redhat dot com> 2012-06-01 17:43:55 UTC ---
There are effectively four possible behaviours for systemtap with respect to
local variables:

- current behaviour: locals are not mangled. The tapset writer has to take care
to avoid collisions.

- platonically ideal behaviour: locals are all prefixed with "l_" to avoid
collisions.

- Josh Stone's suggested compromise: locals are mangled in script functions,
but not in embedded-C functions. Fairly straightforward, though any embedded-C
expressions that access locals *must* be rewritten (if I understand correctly).

- another possibility: some ugly preprocessor hacking is used to temporarily
#define foo l_foo at the beginning of each embedded C block for any locals foo
used within the block; then restore any old definition that foo might have had
at the end. This lets us allow use of *either* mangled or unmangled names in
all embedded code. Then we can gradually transition over to mangled names,
deprecate the unmangled usage, and then take the ugly preprocessor hack back
out (if we want). The specific hack I have in mind here requires #pragma
pushdef/popdef, which is only available as of GCC 4.4.7.

This whole mess of possibilities definitely needs to be hidden behind an
ARG(foo) macro.

It'll be necessary to do some more mulling over of how we want to do this,
especially in terms of compatibility with old gcc versions, how quickly we can
deprecate the old behaviour, any special backwards-compatibility options we
want to enable, etc.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug translator/10299] mangle local variable names

[jistone at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=10299

Josh Stone <jistone at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jistone at redhat dot com

--- Comment #5 from Josh Stone <jistone at redhat dot com> 2012-06-01 22:02:48 UTC ---
(In reply to comment #4)
> There are effectively four possible behaviours for systemtap with respect to
> local variables:
> 
> - current behaviour: locals are not mangled. The tapset writer has to take care
> to avoid collisions.

Yes, but it's not just tapset writers, rather *anybody* writing stap script. 
Even comment 0 is showing just a command-line script triggering problems.

> - platonically ideal behaviour: locals are all prefixed with "l_" to avoid
> collisions.
> 
> - Josh Stone's suggested compromise: locals are mangled in script functions,
> but not in embedded-C functions. Fairly straightforward, though any embedded-C
> expressions that access locals *must* be rewritten (if I understand correctly).

I don't think we want embedded-C expressions to use locals at all - do we have
any in-tree cases that do so?  IMO this should be discouraged, if not outright
forbidden.

The problem with that is akin to asm("") blocks, but those have the benefit of
input/output constraints.  We have no idea which locals are used within an
embedded-C block, so right now we assume none, and our optimization passes act
accordingly.

> - another possibility: some ugly preprocessor hacking is used to temporarily
> #define foo l_foo at the beginning of each embedded C block for any locals foo
> used within the block; then restore any old definition that foo might have had
> at the end. This lets us allow use of *either* mangled or unmangled names in
> all embedded code. Then we can gradually transition over to mangled names,
> deprecate the unmangled usage, and then take the ugly preprocessor hack back
> out (if we want). The specific hack I have in mind here requires #pragma
> pushdef/popdef, which is only available as of GCC 4.4.7.

I think this is fragile.  Imagine if the name is something like "do",
"unsigned", or "void".  Each of these would break in pretty uninteresting ways
if #defined to l_foo, but I worry what someone with more than a few minutes
might come up with.

> This whole mess of possibilities definitely needs to be hidden behind an
> ARG(foo) macro.

Even if we leave embedded-c functions alone for now, I like the idea of
starting to abstract them into ARG(foo) so we are more flexible to change it in
the future.  In fact, I don't think the l_ prefix should ever be documented to
script/tapset writers, rather left as an implementation detail.

> It'll be necessary to do some more mulling over of how we want to do this,
> especially in terms of compatibility with old gcc versions, how quickly we can
> deprecate the old behaviour, any special backwards-compatibility options we
> want to enable, etc.

I think at least for embedded-C functions, we can just introduce #define
ARG(foo) THIS->foo, with a deprecation note that this will be the only
available form in the future.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug translator/10299] mangle local variable names

[smakarov at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=10299

Serguei Makarov <smakarov at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|systemtap at sourceware dot |smakarov at redhat dot com
                   |org                         |

--- Comment #6 from Serguei Makarov <smakarov at redhat dot com> 2012-06-07 20:04:55 UTC ---
Created attachment 6440
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6440
Basic update of translator naming behaviour

This is (tentatively speaking) a patch that changes translate.cxx to generate
mangled local names. It seems to work well, excepting of course when we use
existing code with embedded-C functions.

It might be possible to just update all of the tapsets to use some ARG(foo)
macro, add a command line flag (or similar) to cause the translator to return
to the old mangling behaviour, and that would probably wrap up work on the bug.

The other viable alternative is jistone's suggestion of using different
mangling behaviour for embedded-C functions versus regular functions. It will
be a bit tricky to get this information available at the time when we do
mangling in the current design.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug translator/10299] mangle local variable names

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-06-19 02:03 -------
If we decide to mangle parameters to embedded-C too, then we might want to add
ARG(foo) to PR10300.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10299

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/10299] mangle local variable names

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-06-19 00:03 -------
For script-level names, we can certainly mangle however we like, but how will
this work with embedded-C functions?

  function inc:long(current:long) %{ THIS->__retvalue = THIS->current + 1; %}

Do we want to mangle that too and break the current syntax of THIS?  Or do we
make a special case that embedded functions aren't mangled?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10299

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.