This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug translator/11207] Support preprocessor macros


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

--- Comment #5 from Josh Stone <jistone at redhat dot com> 2012-06-01 22:55:10 UTC ---
I feel like both proposals are a bit too focused on your specific need, to
simplify writing repetitive tapsets.  As far as language features go, plain old
user scripts should be just as capable as tapset files.

For instance, a user could have a lot of @casts to type foo.  They should be
able to define some FOO(ptr) as @cast(ptr, "struct foo",
"/path/to/app:<sys/foo.h"), so they can simplify their accesses as FOO(p)->bar,
FOO(p)->baz, etc.

(In reply to comment #3)
> First version of proposal for just using m4

So that's my primary objection with this approach - that it's *only* available
for tapsets during systemtap's own build.  Also, even if postponed to runtime,
using m4 (or any external preprocessor) won't let us track errors through macro
levels.


(In reply to comment #4)
> First version of custom syntax proposal

I like the %foo shorthand, and parameterized %foo(p1, p2) as well, except for
the ambiguity with the modulus operator.  Maybe we can just accept that though.
 For example, an expression like "x%(y-1)" already fails for a similar reason,
where the "%(" is misinterpreted as starting the preprocessor.  If we accept
that, then I actually prefer this over the %( foo p1 p2 %) form.

I think you need to have a real delimiter between the parameters though, if
only a comma, or else parameters will be limited to a single token, which is
much less flexible.  We can deal with what's our comma vs. a comma within the
parameter in the same way CPP does, which I think is just with parentheses.

Similarly, I don't care for the "\n multi-line-param_n" form, but I think it's
also essentially solved by using CPP-style commas and parentheses.  Let me know
if you think otherwise.

The docstring case is interesting, as usually those are in comments that our
parser completely throws away, so your tapset-generating use case is adding a
requirement I hadn't though of.  Since we generate tapset docs during the
systemtap build, would these be bootstrapped through the stap executable?  Then
there's cross compilation to worry about, so it may have to be a separate mini
parser compiled for the host machine.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]