Bug #25568's introduced capabilities to specify probes by build-id, but this is not very user friendly. What users tend to see directly are file names, and occasionally filenames from archives that are not even installed. The attachment is a demonstration prototype for a stap front-end that can take a path name and a list of RPM-containing directories. It computes a buildid-based script template based on finding all buildids for the given path name in any of the RPMs found, and then compiles than via stap -p4. It uses a temporary instance of debuginfod to build/serve the buildid executables / debuginfo. % sh stap-multirpm /usr/bin/vi /path/to/RPMs [starts debuginfod -R /path/to/RPMs ...] [chance to edit template SCRIPT.stp] [compiles to stap_hexcode.ko] [kills debuginfod] % sudo staprun stap_hexcode.ko & % /usr/bin/vi # of any version from any of those RPMs [watch stap probe hit] We should consider growing some native systemtap syntax for this. Suggestions welcome. Possibility: probe rpmsearch("/path/to/RPMs/prefix*").process("/path/name").function(...) { } probe debsearch(...) { }
Created attachment 13221 [details] proof of concept shell script
Created attachment 14322 [details] Submit A Patch for 27410 The following expands on the original proposal. This patch allows for the user to probe processes similarly to regular process("PATH").** probes but instead searches the current federation of debuginfod servers instead of the host file system. The new syntax which would achieve the original task is as follows: $ debuginfod -R /path/to/RPMs/prefix $ env DEBUGINFOD_URLS=http://localhost:8002/ stap -e 'probe debuginfod.process("/path/name").function(...) { }'
commit a2d19c8670690f87ee74db4a106829aa8edefbce Author: Ryan Goldberg <rgoldber@redhat.com> Date: Fri, 25 Aug 2023 14:20:09 +0000 (10:20 -0400) PR27410: Probe processes using debuginfod New tapset which allows for process probing using executables/debuginfo stored in debuginfod servers.