| Summary: | Load tapsets from $libdir for multiarch | ||
|---|---|---|---|
| Product: | systemtap | Reporter: | Philip Withnall <bugzilla> |
| Component: | tapsets | Assignee: | Unassigned <systemtap> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | fche, simon.mcvittie |
| Priority: | P2 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| See Also: | https://sourceware.org/bugzilla/show_bug.cgi?id=10485 | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | 2016-06-16 00:00:00 | |
|
Description
Philip Withnall
2016-06-16 17:16:00 UTC
Philip, systemtap has something similar already there: /usr/share/systemtap/tapset/$TARGET_ARCH/*.stp is searched in addition to /usr/share/systemtap/tapset/*.stp Plus an individual .stp file may contain %( arch == "x86-64" %? ... %) type preprocessor conditionals. Do these mechanisms suffice? (In reply to Frank Ch. Eigler from comment #1) > Philip, systemtap has something similar already there: > > /usr/share/systemtap/tapset/$TARGET_ARCH/*.stp > > is searched in addition to > > /usr/share/systemtap/tapset/*.stp I think the point is that the FHS defines /usr/share to be "Architecture-independent (shared) data.". Having an architecture-specific subdirectory inside it is a bit awkward. A related problem is that if I have a custom (hacked up) copy of a library (for example, which I'm testing in a process by loading with LD_PRELOAD from $HOME), the .stp file for it will never be found. If the hacked up library contains new probe points, they can't be used. I think a nice solution would be if bug #20203 were fixed first, then systemtap can be changed to look in the 'systemtap' subdirectory next to each library for its .stp files. If bug #20203 is fixed, systemtap will already know which directory each library has been resolved to be in; and hence it will not need to hard-code a list of extra possible $libdirs to check. For example, that means .stp files would normally be installed in $libdir/systemtap/*.stp (where $libdir is the _library_'s $libdir, not necessarily systemtap's $libdir). In the LD_PRELOAD case above, I could put my hacked library in $HOME/libblah.so; and the hacked .stp script in $HOME/systemtap/libblah.so.stp. In the case of Debian multiarch, .stp files would be in /usr/lib/$multiarch_tuple/systemtap/*.stp. Of course, systemtap should also still look in /usr/share/systemtap/tapset for non-architecture-dependent .stp scripts. > Plus an individual .stp file may contain %( arch == "x86-64" %? ... %) type > preprocessor conditionals. Do these mechanisms suffice? Given that this affects the process() call for each probe, that essentially equates to wrapping the entire file in a preprocessor conditional. (In reply to Philip Withnall from comment #2) > A related problem is that if I have a custom (hacked up) copy of a library > (for example, which I'm testing in a process by loading with LD_PRELOAD from > $HOME), the .stp file for it will never be found. If the hacked up library > contains new probe points, they can't be used. It can. For such cases, you could put your tapset.stp file anywhere you like, and add its directory to stap's search path with -I. Your .stp file can contain the full path name of your preloaded .so in its probe alias. > I think a nice solution would be if bug #20203 were fixed first, then > systemtap can be changed to look in the 'systemtap' subdirectory next to > each library for its .stp files. That wouldn't work too well, in that enumration and parsing of all .stp files occurs earlier than analysis of the probe points listed in those .stp files. (In reply to Frank Ch. Eigler from comment #3) > (In reply to Philip Withnall from comment #2) > > A related problem is that if I have a custom (hacked up) copy of a library > > (for example, which I'm testing in a process by loading with LD_PRELOAD from > > $HOME), the .stp file for it will never be found. If the hacked up library > > contains new probe points, they can't be used. > > It can. For such cases, you could put your tapset.stp file anywhere you > like, and add its directory to stap's search path with -I. Your .stp file > can contain the full path name of your preloaded .so in its probe alias. True, but it would be nice if this worked without the need to manually add a -I argument. > > I think a nice solution would be if bug #20203 were fixed first, then > > systemtap can be changed to look in the 'systemtap' subdirectory next to > > each library for its .stp files. > > That wouldn't work too well, in that enumration and parsing of all .stp > files occurs earlier than analysis of the probe points listed in those .stp > files. Hmm. So the problem is that .stp files need to be loaded before the .so files are looked at. For user-space probing, would it be possible to enumerate the libraries in a process' address space, work out the library paths, append 'systemtap' to all of them, then search for .stp files in those directories? > Hmm. So the problem is that .stp files need to be loaded before the .so > files are looked at. For user-space probing, would it be possible to > enumerate the libraries in a process' address space, work out the library > paths, append 'systemtap' to all of them, then search for .stp files in > those directories? That could be implementable - though which process? stap -x $PID is apprx. the only way to refer to a single existing process. You might find bug #10485 a more general solution. It relies on placement of tapset .stp files under a searchably small hierarchy under an existing tapset/ directory. a reasonable concept but not that pressing / compelling |