From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17151 invoked by alias); 17 Apr 2014 18:22:54 -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 17122 invoked by uid 48); 17 Apr 2014 18:22:50 -0000 From: "jlebon at redhat dot com" To: systemtap@sourceware.org Subject: [Bug translator/16615] don't require access to dwarf_query in has_single_line_record() Date: Thu, 17 Apr 2014 18:22:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed 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: jlebon at redhat dot com X-Bugzilla-Status: NEW 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: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-q2/txt/msg00074.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=16615 --- Comment #3 from Jonathan Lebon --- I've just updated the jlebon/pr16615 branch containing many new goodies for statement probes. 1. SPEED We no longer rely on dwarf_getsrc_file(), which is slow, imprecise, and has funny behaviours. Instead, we get our Dwarf_Lines straight from dwarf_getsrclines(), which elfutils already caches, and then we cache our own processed version of it. The results are much faster speeds: $ # OLD STAP $ time sh -c 'stap -l '\''process.statement("*@*:*")'\'' -c stap | wc -l' 13071 real 25m49.115s user 25m47.171s sys 0m0.268s $ # NEW STAP $ time sh -c 'stap -l '\''process.statement("*@*:*")'\'' -c stap | wc -l' 54221 real 1m49.447s user 1m44.032s sys 0m5.304s More realistically, even simple kernel statement probes are faster to resolve: $ # OLD STAP $ time sh -c 'stap -l '\''kernel.statement("bio_init@bio.c:*")'\'' | wc -l' 1 real 0m8.338s user 0m8.259s sys 0m0.039s $ $ # NEW STAP $ time sh -c 'stap -l '\''kernel.statement("bio_init@bio.c:*")'\'' | wc -l' 4 real 0m0.395s user 0m0.360s sys 0m0.032s $ 2. INLINED FUNCTIONS We previously just skipped linenos with multiple addresses. We're now smarter about choosing them by tracking which ones are in which DIEs. This greatly helps inlined functions: $ nl -b a inlines.c 1 2 __attribute__((always_inline)) 3 static void foo(int i) 4 { 5 printf("%d\n", i); 6 } 7 8 int main(int argc, char** argv) 9 { 10 // This is a comment 11 foo(argc); 12 foo(argc*2); 13 return 0; 14 } $ $ gcc -g -w inlines.c -o inlines $ $ # OLD STAP $ stap -e 'probe process.statement("foo@inlines.c:5") { printf("in foo with i=%d\n", $i) }' -c ./inlines semantic error: multiple addresses for /home/yyz/jlebon/codebase/systemtap/systemtap/inlines.c:5 [man error::dwarf] (try /home/yyz/jlebon/codebase/systemtap/systemtap/inlines.c:4) semantic error: while resolving probe point: identifier 'process' at :1:7 source: probe process.statement("foo@inlines.c:5") { printf("in foo with i=%d\n", $i) } ^ semantic error: no match Pass 2: analysis failed. [man error::pass2] $ $ # NEW STAP $ stap -e 'probe process.statement("foo@inlines.c:5") { printf("in foo with i=%d\n", $i) }' -c ./inlines 1 2 in foo with i=1 in foo with i=2 $ 3. ACCURACY Cross-checking against DIEs also allows us to confidently pick the right addr, even when there are multiple Dwarf_Lines at the same lineno. This gives us greater coverage in many optimized functions: $ # OLD STAP $ stap -l 'kernel.statement("bio_init@bio.c:*")' kernel.statement("bio_init@fs/bio.c:277") $ stap -l 'kernel.statement("bio_reset@bio.c:*")' kernel.statement("bio_reset@fs/bio.c:297") kernel.statement("bio_reset@fs/bio.c:298") $ # NEW STAP $ stap -l 'kernel.statement("bio_init@bio.c:*")' kernel.statement("bio_init@fs/bio.c:273") kernel.statement("bio_init@fs/bio.c:274") kernel.statement("bio_init@fs/bio.c:275") kernel.statement("bio_init@fs/bio.c:277") $ stap -l 'kernel.statement("bio_reset@bio.c:*")' kernel.statement("bio_reset@fs/bio.c:291") kernel.statement("bio_reset@fs/bio.c:292") kernel.statement("bio_reset@fs/bio.c:296") kernel.statement("bio_reset@fs/bio.c:297") kernel.statement("bio_reset@fs/bio.c:298") Hopefully, the new code is now more consistent with users' expectations and easier to understand. -- You are receiving this mail because: You are the assignee for the bug.