From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107986 invoked by alias); 21 Jul 2016 14:55:17 -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 107920 invoked by uid 48); 21 Jul 2016 14:55:05 -0000 From: "dsmith at redhat dot com" To: systemtap@sourceware.org Subject: [Bug translator/20394] New: inconsistency in exe/library paths searching between @cast() and process.library.function probes Date: Thu, 21 Jul 2016 14:55:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: translator X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dsmith at redhat dot com X-Bugzilla-Status: NEW 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: 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-q3/txt/msg00080.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D20394 Bug ID: 20394 Summary: inconsistency in exe/library paths searching between @cast() and process.library.function probes Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: translator Assignee: systemtap at sourceware dot org Reporter: dsmith at redhat dot com Target Milestone: --- When writing probes, you can do the following: =3D=3D=3D=3D probe process("python").library("libpython2.7.so*").function("PyEval_EvalFrameE= x") { # ... probe contents here ... } =3D=3D=3D=3D Notice that I'm just probing "python" as the "process" argument, a non-abso= lute path. The translator will look up "python" in my PATH and find it. Notice I= 'm using a wildcarded and non-absolute path for the "library" argument. The above works fine and is very user friendly. So, when using @cast(), I'd like to specify the symbol search path the same way: =3D=3D=3D=3D # cat pytest1.stp function foo:long(object:long) { printf("%d\n", @cast(object, "PyFrameObject", "python:libpython2.7.so*")->f_linen= o) } probe=20 process("python").library("libpython2.7.so*").function("PyEval_EvalFrameE= x") { foo($f) exit() } # stap -v ./pytest1.stp -c "python -c 'import sys; sys.exit(0)'" Pass 1: parsed user script and 117 library scripts using 242808virt/39472res/7568shr/32212data kb, in 190usr/30sys/234real ms. semantic error: while processing function foo semantic error: type definition 'PyFrameObject' not found in 'python:libpython2.7.so*': operator '@cast' at ./pytest1.stp:4:3 source: @cast(object, "PyFrameObject", "python:libpython2.7.so*")->f_lineno) ^ Pass 2: analyzed script: 1 probe, 1 function, 0 embeds, 0 globals using 250612virt/48776res/8880shr/40016data kb, in 120usr/380sys/498real ms. Pass 2: analysis failed. [man error::pass2] =3D=3D=3D=3D So, that didn't work. Let's try without the wildcard: =3D=3D=3D=3D # cat pytest2.stp function foo:long(object:long) { printf("%d\n", @cast(object, "PyFrameObject", "python:libpython2.7.so")->f_lineno) } probe=20 process("python").library("libpython2.7.so*").function("PyEval_EvalFrameE= x") { foo($f) exit() } # stap -v ./pytest2.stp -c "python -c 'import sys; sys.exit(0)'" Pass 1: parsed user script and 117 library scripts using 242808virt/39644res/7740shr/32212data kb, in 200usr/40sys/240real ms. semantic error: while processing function foo semantic error: type definition 'PyFrameObject' not found in 'python:libpython2.7.so': operator '@cast' at ./pytest2.stp:4:3 source: @cast(object, "PyFrameObject", "python:libpython2.7.so")->f_lineno) ^ Pass 2: analyzed script: 1 probe, 3 functions, 0 embeds, 0 globals using 250608virt/48792res/8892shr/40012data kb, in 100usr/400sys/511real ms. Pass 2: analysis failed. [man error::pass2] =3D=3D=3D=3D OK, on this system /usr/lib64/libpython2.7.so is a symbolic link to /usr/lib64/libpython2.7.so.1.0. Let's give that a shot: =3D=3D=3D=3D # cat pytest3.stp function foo:long(object:long) { printf("%d\n", @cast(object, "PyFrameObject", "python:libpython2.7.so.1.0")->f_lineno) } probe=20 process("python").library("libpython2.7.so*").function("PyEval_EvalFrameE= x") { foo($f) exit() } # stap -v ./pytest3.stp -c "python -c 'import sys; sys.exit(0)'" Pass 1: parsed user script and 117 library scripts using 242804virt/39504res/7604shr/32208data kb, in 210usr/30sys/242real ms. semantic error: while processing function foo semantic error: type definition 'PyFrameObject' not found in 'python:libpython2.7.so.1.0': operator '@cast' at ./pytest3.stp:4:3 source: @cast(object, "PyFrameObject", "python:libpython2.7.so.1.0")->f_lineno) ^ Pass 2: analyzed script: 1 probe, 1 function, 0 embeds, 0 globals using 250608virt/48804res/8912shr/40012data kb, in 100usr/370sys/492real ms. Pass 2: analysis failed. [man error::pass2] =3D=3D=3D=3D Nope. The only thing I can seem to get to work for @cast() is a full absolute pat= h to the library. One reason why this is annoying is that to handle both 32-bit distros and 64-bit distros, I'll have to specify the library in both /usr/l= ib/ and /usr/lib64: =3D=3D=3D=3D # cat pytest4.stp function foo:long(object:long) { printf("%d\n", @cast(object, "PyFrameObject", "python:/usr/lib64/libpython2.7.so:/usr/lib/libpython2.7.so")->f_lineno) } probe=20 process("python").library("libpython2.7.so*").function("PyEval_EvalFrameE= x") { foo($f) exit() } # stap -v ./pytest4.stp -c "python -c 'import sys; sys.exit(0)'" Pass 1: parsed user script and 117 library scripts using 242808virt/39712res/7812shr/32212data kb, in 210usr/30sys/238real ms. Pass 2: analyzed script: 1 probe, 4 functions, 0 embeds, 0 globals using 251388virt/49532res/8828shr/40792data kb, in 120usr/190sys/317real ms. Pass 3: translated to C into "/tmp/stapYGfpK4/stap_d4c98f72a2d5b7cef816271d6bd3e397_3084_src.c" using 251388virt/49724res/9020shr/40792data kb, in 20usr/190sys/206real ms. Pass 4: compiled C into "stap_d4c98f72a2d5b7cef816271d6bd3e397_3084.ko" in 4730usr/1000sys/5459real ms. Pass 5: starting run. 59 Pass 5: run completed in 30usr/70sys/392real ms. =3D=3D=3D=3D --=20 You are receiving this mail because: You are the assignee for the bug.