[Bug translator/10299] mangle local variable names

["jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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.