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 translator/16500] New: provide a way for users to retrieve probe point arguments in a consistent manner


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.


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