The attached patch implements initial support for SystemTap to use Srikar's inode-based uprobes. It is also published in the branch jistone/inode-uprobes, in gitweb here: The uprobes branch I worked from is here: The good news is that the basics appear to be working well. I've tested probing stap itself and libdw, and got the expected probe hits. I'd appreciate any review of my implementation so far. Beyond these working basics, there are a lot of details to hammer out, so here's the list of what I know. * EXPORT_SYMBOL_GPL, or uprobes' lack thereof. Without kernel exports, the whole API will be inaccessible to us. * Return probes. This hasn't yet been added to the new uprobes. * Process filtering. AFAICS, the current uprobes implementation sets the breakpoint in all processes that map the particular inode. There is a filtering mechanism, but that seems only to decide whether to call the handler each time. You'll still take the bp/sstep overhead. Also, on stap's side, we previously had the ability to limit process probes to the -x/-c target and children, which I haven't tried here yet. * Runtime build-id verification. Right now I'm just mapping the path to inode*, without checking that the build-id is what we expected. I'm not sure we even could at the systemtap-init point. Even if we did, the file may still get modified without changing the inode, and I don't think this uprobes gives us any way to notice or decide whether we like the new form. * SDT semaphore. In the current form, we have no hook on individual processes, so we can't modify the semaphores in applications that are actively gating their markers. We'll probably need something like PR10994 to achieve this, which isn't really about uprobes per-se, but rather about living without utrace. * Argument access. If you try $args, it will fail with a missing symbol 'task_user_regset_view'. I haven't looked closely at this yet. * Probe IP. For many probe handlers, we try to set the pt_regs IP to the actual breakpoint IP, but in this case we don't happen to even know the virtualized address. Uprobes itself uses uprobes_get_bkpt_addr() in some instances, but that's not exposed for our use. I think that's it. So if you happen to build a kernel with the new uprobes, please enjoy systemtap support too. :) Josh