This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/16500] New: provide a way for users to retrieve probe point arguments in a consistent manner
- From: "jlebon at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Wed, 22 Jan 2014 22:16:47 +0000
- Subject: [Bug translator/16500] New: provide a way for users to retrieve probe point arguments in a consistent manner
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=16500
Bug ID: 16500
Summary: provide a way for users to retrieve probe point
arguments in a consistent manner
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: translator
Assignee: systemtap at sourceware dot org
Reporter: jlebon at redhat dot com
Discussing with Josh on IRC, we thought it would be nice to have a consistent
method of accessing probe point arguments, rather than having an array of
tapset functions.
E.g. one possibility is to have something like @pp("function"), or instead (if
it helps the type_resolution pass), @ppstr("function") and @ppnum("statement").
Something like this could be expanded at translate-time to a lookup into
runtime structures to retrieve the appropriate information.
This would be easy for things we already have, e.g. function, process, module.
But it might require including more info in the module for things that have
been translated away, e.g. label->function@file:line, or plt->statement(num).
We can't always rely on parsing probe_name, since it may be hidden behind
aliases. And probe_point has only the final resolution components and
arguments.
--
You are receiving this mail because:
You are the assignee for the bug.