This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/17986] unprivileged_myproc.exp and unprivileged_probes.exp regressed on el6 (systemtap-2.5-5.el6 versus release-2.6-274-gbabad5b31b70)
- From: "jlebon at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Thu, 19 Feb 2015 21:27:03 +0000
- Subject: [Bug runtime/17986] unprivileged_myproc.exp and unprivileged_probes.exp regressed on el6 (systemtap-2.5-5.el6 versus release-2.6-274-gbabad5b31b70)
- Auto-submitted: auto-generated
- References: <bug-17986-6586 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=17986
--- Comment #2 from Jonathan Lebon <jlebon at redhat dot com> ---
(In reply to David Smith from comment #1)
>
> Jonathan, should a .nearest probe to a wildcarded line number work?
Hi David,
I think it could go either way, although my preference would be for not
allowing it simply because it doesn't do anything useful. See also bug 17906:
> Thanks for reporting this, looks like I didn't catch it when I made the change. If I remember correctly, the reasoning was that it didn't make sense to have wildcards with .nearest. E.g. .statement("foo@file.c:15").nearest and .statement("foo@file.c+3").nearest have clear meanings (use the nearest probe-able addrs to these linenos).
>
> On the other hand, with .statement("foo@file.c:*").nearest, since "*" already means "expand to all possible probe-able linenos", adding a .nearest makes no difference since they will all already be valid linenos. In that sense, I guess we could allow the syntax without really changing behaviour. At the time, I leaned on the stricter interpretation of "this is redundant so the user probably meant something else".
--
You are receiving this mail because:
You are the assignee for the bug.