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 #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.

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