This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/10299] mangle local variable names
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Fri, 01 Jun 2012 22:02:48 +0000
- Subject: [Bug translator/10299] mangle local variable names
- Auto-submitted: auto-generated
- References: <bug-10299-6586@http.sourceware.org/bugzilla/>
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.