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 runtime/17986] unprivileged_myproc.exp and unprivileged_probes.exp regressed on el6 (systemtap-2.5-5.el6 versus release-2.6-274-gbabad5b31b70)


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.


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