[Bug runtime/18714] New: bring back process.statement.absolute probes

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug runtime/18714] New: bring back process.statement.absolute probes

github at kalvdans dot no-ip.org
https://sourceware.org/bugzilla/show_bug.cgi?id=18714

            Bug ID: 18714
           Summary: bring back   process.statement.absolute probes
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: fche at redhat dot com
  Target Milestone: ---

While inode-uprobes makes $subject probe type not trivially available, we
should still be able to hack around it in the runtime.  Given the requested
virtual address, aat registration time we could walk the process address space,
find the inode & offset corresponding to that address (if any!), and place a
inode+offset uprobe there.  (This doesn't help non-inode gaps in the address
space, alas.)

--
You are receiving this mail because:
You are the assignee for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug runtime/18714] bring back process.statement.absolute probes

github at kalvdans dot no-ip.org
https://sourceware.org/bugzilla/show_bug.cgi?id=18714

agentzh <agentzh at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |agentzh at gmail dot com

--- Comment #1 from agentzh <agentzh at gmail dot com> ---
We'll take a stab at implementing `process.statement(0xaddr)` first for
inode-based uprobes, with relative addresses in the executable files (including
DSO and PIE). This will pave a way to true DWARF-less probing (with the
existing @vma() facility which will get merge soon) as well as implementing our
own uretprobes without all the consequences from the kernel's uretprobes.
Messed up C stacks are really problematic for stack unwinding and resizable
stacks.

--
You are receiving this mail because:
You are the assignee for the bug.