From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24151 invoked by alias); 16 Jun 2016 20:14:56 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 24038 invoked by uid 48); 16 Jun 2016 20:14:43 -0000 From: "bugzilla at tecnocode dot co.uk" To: systemtap@sourceware.org Subject: [Bug tapsets/20264] Load tapsets from $libdir for multiarch Date: Thu, 16 Jun 2016 20:14:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: tapsets X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bugzilla at tecnocode dot co.uk X-Bugzilla-Status: WAITING X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2016-q2/txt/msg00241.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D20264 --- Comment #2 from Philip Withnall --- (In reply to Frank Ch. Eigler from comment #1) > Philip, systemtap has something similar already there:=20 >=20 > /usr/share/systemtap/tapset/$TARGET_ARCH/*.stp >=20 > is searched in addition to >=20 > /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 $HO= ME), 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 syste= mtap 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 ne= ed 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 =3D=3D "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. --=20 You are receiving this mail because: You are the assignee for the bug.