From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8275 invoked by alias); 28 May 2013 21:36:06 -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 8265 invoked by uid 89); 28 May 2013 21:36:06 -0000 X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS,TW_KP autolearn=ham version=3.3.1 Received: from mail-bk0-f47.google.com (HELO mail-bk0-f47.google.com) (209.85.214.47) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 28 May 2013 21:36:05 +0000 Received: by mail-bk0-f47.google.com with SMTP id jg1so4444186bkc.6 for ; Tue, 28 May 2013 14:36:03 -0700 (PDT) X-Received: by 10.204.169.137 with SMTP id z9mr14091966bky.33.1369776963081; Tue, 28 May 2013 14:36:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.202.205 with HTTP; Tue, 28 May 2013 14:35:42 -0700 (PDT) In-Reply-To: <20130528203223.GA768@toonder.wildebeest.org> References: <1360054656.3837.13.camel@bordewijk.wildebeest.org> <51114188.60400@redhat.com> <20130528191449.GA31042@toonder.wildebeest.org> <51A511FD.8010006@redhat.com> <20130528203223.GA768@toonder.wildebeest.org> From: Zheng Da Date: Tue, 28 May 2013 21:36:00 -0000 Message-ID: Subject: Re: [BUG] syscall.unlink no longer works after upgrading kernel to 3.7.3 To: Mark Wielaard Cc: Josh Stone , agentzh , "systemtap@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-q2/txt/msg00203.txt.bz2 Yes, it's my own script. Here is the code: probe kernel.function("scsi_device_unbusy") { if ($sdev->host->host_no == 9 && $sdev->id == 1) { printf("sdev on node %d, host on node %d\n", addr_to_node($sdev), addr_to_node($sdev->host)); exit(); } } The script works in Linux 3.2.12. systemtap actually can find the right location of scsi_device_unbusy, but it doesn't show its parameters. $ stap -L 'kernel.function("scsi_device_unbusy")' kernel.function("scsi_device_unbusy@drivers/scsi/scsi_lib.c:318") I run eu-readelf -N --debug-dump=info /usr/lib/debug/lib/modules/3.8.12/vmlinux and the info of scsi_device_unbusy is shown below: [43d72e9] subprogram external (flag) Yes name (strp) "scsi_device_unbusy" decl_file (data1) 1 decl_line (data2) 318 prototyped (flag) Yes low_pc (addr) 0xffffffff81480e80 high_pc (addr) 0xffffffff81480f44 frame_base (data4) location list [e061d3] sibling (ref4) [43d7492] [43d730b] formal_parameter name (strp) "sdev" decl_file (data1) 1 decl_line (data2) 318 type (ref4) [43d22ff] location (data4) location list [e06233] [43d731b] variable name (strp) "shost" decl_file (data1) 1 decl_line (data2) 320 type (ref4) [43d286d] location (data4) location list [e06269] [43d732b] variable name (strp) "starget" decl_file (data1) 1 decl_line (data2) 321 type (ref4) [43d29be] [43d7337] variable name (strp) "flags" decl_file (data1) 1 decl_line (data2) 322 type (ref4) [43c2d16] location (data4) location list [e062b4] It seems the function isn't inlined and eu-readelf can read all right info of its parameter. Right now the OS has debug info of two kernels. $ ls /usr/lib/debug/lib/modules/ 3.2.30 3.8.12 When the OS uses kernel v3.8.12, stap can still read the right info of scsi_device_unbusy if I specify version 3.2.30. $ stap -r 3.2.30 -L 'kernel.function("scsi_device_unbusy")' kernel.function("scsi_device_unbusy@drivers/scsi/scsi_lib.c:302") $sdev:struct scsi_device* I built kernel 3.8.12 with debug info in the same way as I did with 3.2.30. I checked the config file of kernel 3.8.12, all configs mentioned in http://sourceware.org/systemtap/wiki/SystemTapWithSelfBuiltKernel has been enabled. Basically, I run the following in Ubuntu. fakeroot make-kpkg -j8 --initrd --revision=1.0 kernel_image kernel_debug Josh, when you say "DWARF dump", do you mean the output of eu-readelf as I did above? Thanks, Da On Tue, May 28, 2013 at 4:32 PM, Mark Wielaard wrote: > On Tue, May 28, 2013 at 01:22:21PM -0700, Josh Stone wrote: >> But there are other reasons for "not accessible" errors, as described in >> "man error::dwarf". Just optimization or inlining can be enough to make >> variables unavailable from certain addresses. >> >> Are you able to look at the DWARF dump to see where that variable can be >> reached? > > See also http://sourceware.org/systemtap/wiki/TipContextVariables > for some hints and tips on tracking down what could be the real issue.