This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug tapsets/12748] need syscall-number database in tapset
- From: "dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Mon, 20 Jun 2016 18:21:53 +0000
- Subject: [Bug tapsets/12748] need syscall-number database in tapset
- Auto-submitted: auto-generated
- References: <bug-12748-6586 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=12748
--- Comment #4 from David Smith <dsmith at redhat dot com> ---
(In reply to Martin Cermak from comment #2)
> Created attachment 9344 [details]
> Attached patch shows the result of the above generator script, plus it has a
> testsuite bit included.
This bit here:
====
@define return_sanitized(indexable, key)
%(
present = 0
foreach (_key in @indexable)
if (_key == @key)
present = 1
if (present == 0)
return -1
else
return @indexable[@key]
%)
====
can be replaced by the following, so that once we find the key we stop:
====
@define return_sanitized(indexable, key)
%(
present = 0
foreach (_key in @indexable) {
if (_key == @key) {
present = 1
break
}
}
if (present == 0)
return -1
else
return @indexable[@key]
%)
====
However, there is an even easer way. stap has a built-in operator for array
index inclusion - "in":
====
@define return_sanitized(indexable, key)
%(
if (@key in @indexable)
return @indexable[@key]
else
return -1
%)
====
I imagine that the syscall tables themselves will end up in arch-specific
directories. I can't imagine wanting to look up an s390x syscall number on an
x86_64 machine.
--
You are receiving this mail because:
You are the assignee for the bug.