[Bug translator/10299] mangle local variable names

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

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.