[Bug translator/11207] Support preprocessor macros

[Bug translator/11207] Support preprocessor macros

[smakarov at redhat dot com]

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

Serguei Makarov <smakarov at redhat dot com> changed:

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

--- Comment #2 from Serguei Makarov <smakarov at redhat dot com> 2012-06-01 18:03:47 UTC ---
Currently mulling over the two directions (m4, or a custom preprocessor). Still
in progress, but by now it's worthwhile to post the current 'best' ideas as
attachments.

The next step is probably to consider the more natural invocation syntax
mentioned at the bottom of the custom proposal and to try to see what happens
if I just start using m4 in a more adhoc (and potentially ugly) manner, rather
than trying to design-specify-build some comprehensive define_probe_template
macro.

--- Comment #3 from Serguei Makarov <smakarov at redhat dot com> 2012-06-01 18:04:18 UTC ---
Created attachment 6432
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6432
First version of proposal for just using m4

-- 
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/11207] Support preprocessor macros

[smakarov at redhat dot com]

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

Serguei Makarov <smakarov at redhat dot com> changed:

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

--- Comment #2 from Serguei Makarov <smakarov at redhat dot com> 2012-06-01 18:03:47 UTC ---
Currently mulling over the two directions (m4, or a custom preprocessor). Still
in progress, but by now it's worthwhile to post the current 'best' ideas as
attachments.

The next step is probably to consider the more natural invocation syntax
mentioned at the bottom of the custom proposal and to try to see what happens
if I just start using m4 in a more adhoc (and potentially ugly) manner, rather
than trying to design-specify-build some comprehensive define_probe_template
macro.

-- 
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/11207] Support preprocessor macros

[smakarov at redhat dot com]

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

--- Comment #4 from Serguei Makarov <smakarov at redhat dot com> 2012-06-01 18:05:37 UTC ---
Created attachment 6433
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6433
First version of custom syntax proposal

-- 
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/11207] Support preprocessor macros

[jistone at redhat dot com]

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.

[Bug translator/11207] Support preprocessor macros

[smakarov at redhat dot com]

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

--- Comment #6 from Serguei Makarov <smakarov at redhat dot com> 2012-06-12 15:40:58 UTC ---
Please refer to thread "(PR11207) Macroprocessor discussion" on the systemtap
mailing list for further progress on the proposal.

-- 
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/11207] Support preprocessor macros

[smakarov at redhat dot com]

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

Serguei Makarov <smakarov at redhat dot com> changed:

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

-- 
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/11207] Support preprocessor macros

[fche at redhat dot com]

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

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fche at redhat dot com
            Summary|Support preprocessor        |Support preprocessor macros
                   |defines                     |

--- Comment #1 from Frank Ch. Eigler <fche at redhat dot com> 2010-11-11 22:41:08 UTC ---
Another instance of this sort of need is to represent the 
casting/arithmetic magic used in the linux kernel list.h
macros, like 

 void
 inode_to_filename(struct inode *inode)
 {
  struct dentry *dentry = list_first_entry(inode->i_dentry,
        struct dentry, d_alias);
  printk("%.*s\n", dentry->d_name.len, dentry->d_name.name);
 }

where list_first_entry hides quite a bit of stuff that in
our language would expand to @casts etc.  With some more
const-propagation, some of it could be done with an ordinary
script function, but not everything.

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