This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/14297] stap -l and pn() fail to expand complex wildcards
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Wed, 15 May 2013 04:26:46 +0000
- Subject: [Bug translator/14297] stap -l and pn() fail to expand complex wildcards
- Auto-submitted: auto-generated
- References: <bug-14297-6586 at http dot sourceware dot org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=14297
Josh Stone <jistone at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #3 from Josh Stone <jistone at redhat dot com> 2013-05-15 04:26:46 UTC ---
This has caused a regression for aliases:
$ stap -l syscall.open
derived_probe with no locations
Less critical, the plt output seems oddly inconsistent:
$ stap -l 'process("stap").plt("write")'
process("stap").plt("write")
$ stap -l 'process("stap").plt("writ?")'
process("stap").plt("writ?")
$ stap -l 'process("stap").plt("writ[e]")'
process("stap").plt("writ[e]")
$ stap -l 'process("stap").plt("writ*")'
process("stap").plt("write").statement(4243536)?
i.e. only the last form got wildcard expanded, but that exposed the statement
address too. I'd think we want every wildcard-expanded form to list like the
first plain one did.
(and why does the derived plt get marked '?' optional? It seems to have been
this way forever, but I don't see the reason.)
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.