This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug tapsets/20264] Load tapsets from $libdir for multiarch
- From: "bugzilla at tecnocode dot co.uk" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Thu, 16 Jun 2016 20:14:42 +0000
- Subject: [Bug tapsets/20264] Load tapsets from $libdir for multiarch
- Auto-submitted: auto-generated
- References: <bug-20264-6586 at http dot sourceware dot org/bugzilla/>
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.