[Bug tapsets/20264] Load tapsets from $libdir for multiarch

["bugzilla at tecnocode dot co.uk" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20264

--- Comment #2 from Philip Withnall <bugzilla at tecnocode dot co.uk> ---
(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.

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