From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19126 invoked by alias); 21 Jul 2014 18:36:55 -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 19083 invoked by uid 48); 21 Jul 2014 18:36:51 -0000 From: "dsmith at redhat dot com" To: systemtap@sourceware.org Subject: [Bug translator/17190] New: 'stap -l' output not useful as stap input Date: Mon, 21 Jul 2014 18:36: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-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 Message-ID: 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-q3/txt/msg00059.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17190 Bug ID: 17190 Summary: 'stap -l' output not useful as stap input Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: translator Assignee: systemtap at sourceware dot org Reporter: dsmith at redhat dot com While working on bug #17140, I came across this. First use 'stap -l' to get a listing of function probe points: ==== # stap -l 'kernel.function("z*@mm/*.c").call' kernel.function("zap_huge_pmd@mm/huge_memory.c:1412").call kernel.function("zap_page_range@mm/memory.c:1401").call kernel.function("zap_page_range_single@mm/memory.c:1427").call kernel.function("zap_vma_ptes@mm/memory.c:1455").call kernel.function("zone_absent_pages_in_node@mm/page_alloc.c:4506").call kernel.function("zone_balanced@mm/vmscan.c:2675").call kernel.function("zone_batchsize@mm/page_alloc.c:4061").call kernel.function("zone_dirty_ok@mm/page-writeback.c:344").call kernel.function("zone_pcp_reset@mm/page_alloc.c:6178").call kernel.function("zone_pcp_update@mm/page_alloc.c:6172").call kernel.function("zone_reclaimable_pages@mm/vmscan.c:150").call kernel.function("zone_spanned_pages_in_node@mm/page_alloc.c:4445").call kernel.function("zone_wait_table_init@mm/page_alloc.c:4174").call kernel.function("zone_watermark_ok@mm/page_alloc.c:1662").call kernel.function("zone_watermark_ok_safe@mm/page_alloc.c:1669").call kernel.function("zoneinfo_open@mm/vmstat.c:1087").call kernel.function("zoneinfo_show@mm/vmstat.c:1072").call kernel.function("zoneinfo_show_print@mm/vmstat.c:1006").call ==== Now, try to use the first one in a probe: ==== # stap -vp4 -e 'probe kernel.function("zap_huge_pmd@mm/huge_memory.c:1412").call { printf("here\n") }' Pass 1: parsed user script and 105 library script(s) using 143884virt/28892res/3120shr/26140data kb, in 150usr/20sys/550real ms. WARNING: For probing a particular line, use a .statement() probe, not .function(): keyword at :1:1 source: probe kernel.function("zap_huge_pmd@mm/huge_memory.c:1412").call { printf("here\n") } ^ semantic error: no line records for mm/huge_memory.c:1412 [man error::dwarf] (try :1414) semantic error: while resolving probe point: identifier 'kernel' at :1:7 source: probe kernel.function("zap_huge_pmd@mm/huge_memory.c:1412").call { printf("here\n") } ^ semantic error: no match (similar functions: zap_huge_pmd, mk_huge_pmd, copy_huge_pmd, move_huge_pmd, change_huge_pmd) Pass 2: analyzed script: 0 probe(s), 0 function(s), 0 embed(s), 0 global(s) using 159484virt/45176res/3928shr/41740data kb, in 160usr/50sys/1478real ms. Pass 2: analysis failed. [man error::pass2] ==== So, according to stap, zap_huge_pmd() doesn't exist at 1412. It might exist at 1414. Let's give that a shot: ==== stap -vp4 -e 'probe kernel.function("zap_huge_pmd@mm/huge_memory.c:1414").call { printf("here\n") }' Pass 1: parsed user script and 105 library script(s) using 143884virt/28892res/3120shr/26140data kb, in 140usr/10sys/158real ms. WARNING: For probing a particular line, use a .statement() probe, not .function(): keyword at :1:1 source: probe kernel.function("zap_huge_pmd@mm/huge_memory.c:1414").call { printf("here\n") } ^ Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s) using 159884virt/45488res/3900shr/42140data kb, in 220usr/60sys/290real ms. Pass 3: translated to C into "/tmp/stap1FJc9E/stap_13688915453ad5ced72ffb549af941f4_1049_src.c" using 159884virt/45816res/4224shr/42140data kb, in 0usr/40sys/47real ms. /root/.systemtap/cache/13/stap_13688915453ad5ced72ffb549af941f4_1049.ko Pass 4: compiled C into "stap_13688915453ad5ced72ffb549af941f4_1049.ko" in 1110usr/170sys/1278real ms. ==== So, why didn't 'stap -l' tell me the function was at 1414 in the first place? -- You are receiving this mail because: You are the assignee for the bug.