This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]