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

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

[bugzilla at tecnocode dot co.uk]

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

            Bug ID: 20264
           Summary: Load tapsets from $libdir for multiarch
           Product: systemtap
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: bugzilla at tecnocode dot co.uk
  Target Milestone: ---

Tapsets for libraries have the path of the library hard-coded in them, and are
installed in /usr/share at the moment. Architecture-specific hard-coded paths
should not be in /usr/share.

In order to support multiarch, SystemTap should support loading tapsets from
multiarch directories beneath /usr/lib; e.g.
/usr/lib/arm-linux-gnueabihf/systemtap/tapset.

https://wiki.debian.org/Multiarch/Implementation#What_does_the_end_result_look_like.3F

Bug #20203 is about searching the library path for process("mylib.so"); I think
for multiarch we need to keep the full paths in the process() call; but allow
installation of multiple .stp files (one per architecture per library).

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

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

[fche at redhat dot com]

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

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2016-06-16
                 CC|                            |fche at redhat dot com
     Ever confirmed|0                           |1

--- Comment #1 from Frank Ch. Eigler <fche at redhat dot com> ---
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?

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

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

[bugzilla at tecnocode dot co.uk]

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.

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

[bugzilla at tecnocode dot co.uk]

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

Philip Withnall <bugzilla at tecnocode dot co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simon.mcvittie at collabora dot co
                   |                            |.uk

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

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

[fche at redhat dot com]

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

--- Comment #3 from Frank Ch. Eigler <fche at redhat dot com> ---
(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.

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

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

[fche at redhat dot com]

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

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=10485

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

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

[bugzilla at tecnocode dot co.uk]

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

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

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

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

[fche at redhat dot com]

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

--- Comment #5 from Frank Ch. Eigler <fche at redhat dot com> ---
> 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.

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

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

[fche at redhat dot com]

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

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #6 from Frank Ch. Eigler <fche at redhat dot com> ---
a reasonable concept but not that pressing / compelling

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