I am exploring the Myrinet 10G MX driver with SystemTap. I created two markers called mx_ether_xmit_top and mx_ether_xmit_bottom at the top and bottom of static function mx_ether_xmit in mx-1.2.0i/driver/linux/mx_ether.c, part of module mx_driver. Instead of being able to probe at the marks, there are semantic errors: "semantic error: incomplete: keyword at <input>:1:1" with "stap -e 'probe module("mx_driver").mark ("mx_ether_xmit_top") {exit}'". Surprisingly, there is a different error when running "stap -e 'probe module("mx_driver").mark ("mx_ether_xmit") {exit}'": "semantic error: no match for probe point while resolving probe point module("mx_driver").mark("mx_ether_xmit")" which is the error I expect to see since there are no marks by that name. Thus the mark is being found by the first command line. The problem appears to be an incomplete implementation guarded by throwing semantic error "incomplete" in mark_derived_probe::join_group at tapsets.cxx:4382.
We have temporarily turned off marker support in systemtap, since it used the function-pointer style of marker macro I presented at OLS in 2006. The kernel community has not accepted it, and have instead worked on a similar scheme being built by lttng folks. My plan has been to re-enable marker support in systemtap, once the lttng marker facility is finalized and accepted. If that plan does not suit you, there are a couple of options. You could go back to an older version of systemtap that still has the older marker code enabled - sometime late 2006. Or you could try applying kprobes-based probes in your script. Or, you could motivate us to restore support for the old marker code.
Subject: Re: mark_derived_probe::join_group incomplete Thanks for responding so quickly Frank. fche at redhat dot com(sourceware-bugzilla@sourceware.org)@2007.03.30 18:02:01 +0000: > If that plan does not suit you, there are a couple of options. You could go > back to an older version of systemtap that still has the older marker code > enabled - sometime late 2006. Or you could try applying kprobes-based > probes in your script. Or, you could motivate us to restore support for the > old marker code. How difficult would it be for me to temporarily re-enable it? I have a deadline that I am up against and need the feature, but do not mind if the current implementation is not the one that is finally adopted. Mark -- Dr. Mark K. Gardner Network Research Manager Communications Network Services Virginia Tech
If you check out a considerably older version of systemtap, then you will find the old marker code still active. For example, you could check out and build the "rhel5b2" CVS-tagged version of systemtap, which dates from 2006-10-18. That one of course lacks many modern features and compatibility improvements. If this is not acceptable, and you need markers as opposed to kprobes, you will need to wait for someone to forward port the old marker code into the current tree. It wouldn't be much work (a couple of days), but I'm busy with something else right now.
Subject: Re: mark_derived_probe::join_group incomplete Thanks. I'll give the old version a try. Mark fche at redhat dot com(sourceware-bugzilla@sourceware.org)@2007.03.30 18:44:18 +0000: > > ------- Additional Comments From fche at redhat dot com 2007-03-30 19:44 ------- > If you check out a considerably older version of systemtap, then you > will find the old marker code still active. For example, you could > check out and build the "rhel5b2" CVS-tagged version of systemtap, > which dates from 2006-10-18. That one of course lacks many modern > features and compatibility improvements. > > If this is not acceptable, and you need markers as opposed to kprobes, > you will need to wait for someone to forward port the old marker code > into the current tree. It wouldn't be much work (a couple of days), > but I'm busy with something else right now. > > > -- > > > http://sourceware.org/bugzilla/show_bug.cgi?id=4301 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > -- Dr. Mark K. Gardner Network Research Manager Communications Network Services Virginia Tech
Considering that the new marker code appears closer to upstream acceptance, I'd like to avoid forward-porting the support for this old marker style. *** This bug has been marked as a duplicate of 4446 ***