From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11860 invoked by alias); 18 Oct 2006 00:52:12 -0000 Received: (qmail 11815 invoked by uid 22791); 18 Oct 2006 00:52:11 -0000 X-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,TW_BJ,TW_PF,TW_TM X-Spam-Check-By: sourceware.org Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 18 Oct 2006 00:52:07 +0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by mga03.intel.com with ESMTP; 17 Oct 2006 17:52:04 -0700 Received: from orsmsx331.jf.intel.com (HELO orsmsx331.amr.corp.intel.com) ([192.168.65.56]) by azsmga001.ch.intel.com with ESMTP; 17 Oct 2006 17:52:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,321,1157353200"; d="scan'208"; a="132394557:sNHT34211121" Received: from orsmsx419.amr.corp.intel.com ([10.22.226.88]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Oct 2006 17:52:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Stap is translating to functions in __exit sections...and later module load fails Date: Wed, 18 Oct 2006 00:52:00 -0000 Message-ID: <8A3E977AB3C24845947ADAAE0526E395CB8D72@orsmsx419.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stap is translating to functions in __exit sections...and later module load fails thread-index: AcbxFgPEHRciOCu/Qkad9e4NdrDyCgBONqdQ From: "Keshavamurthy, Anil S" To: "Mao, Bibo" , "Eugeniy Meshcheryakov" Cc: "Stone, Joshua I" , "Systemtap" X-OriginalArrivalTime: 18 Oct 2006 00:52:03.0664 (UTC) FILETIME=[A08E0D00:01C6F24F] X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q4/txt/msg00150.txt.bz2 After commenting (i.e not discarding) *(.exit.text) from arch/ia64/kernel/vmlinux.lds.S file and booting with this new kernel,= =20 stap ignores functions in __exit sections and elaborates and translates functions properly. Can someone tell me why this section is not discarded on Ia32? Thanks, -Anil Keshavamurthy -----Original Message----- From: Mao, Bibo=20 Sent: Monday, October 16, 2006 4:27 AM To: Eugeniy Meshcheryakov Cc: Stone, Joshua I; Keshavamurthy, Anil S; Systemtap Subject: Re: Stap is translating to functions in __exit sections...and late= r module load fails I do not think it is gcc bug, I think it depends on ld script, this is part of IA64 linux 2.6.19-rc2 vmlinux.lds.S, SECTIONS { /* Sections to be discarded */ /DISCARD/ : { *(.exit.text) *(.exit.data) *(.exitcall.exit) *(.IA_64.unwind.exit.text) *(.IA_64.unwind_info.exit.text) } ....... it seems that .exit.text is discarded when vmlinux image is linked, and on IA32 .exit.text segment is not discarded, the script stap -e 'probe kernel.function("*") { print(".") }' can run on IA32 platform. it is strange that when exit_pfm_fs is probe there is one such line probe exit_pfm_fs@arch/ia64/kernel/perfmon.c:1507 pc=3D0x0 I do not how function probe-point is parsed, I am not familiar with Elfutils package :( And powerpc has the same ld link script, it should has the same problem. thanks bibo,mao Eugeniy Meshcheryakov wrote: > 13 =D0=B6=D0=BE=D0=B2=D1'=D0=BD=D1=8F 2006 =D0=BE 15:28 -0700 Stone, Josh= ua I =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2(-=D0=BB=D0=B0): >> This seems to support the notion that the linker elided that function. >> >> So, as Eugeniy wondered, why did the translator pick up that function at >> all? I'm also curious what IP it chose for the kprobe, if the function >> no longer exists... Please try this command: >> >> $ stap -p2 -vv -e 'probe kernel.function("exit_pfm_fs"){}' 2>&1 | grep >> 'pc=3D' >> >> I suspect that either elfutils is giving 'stale' debug information, or >> the translator is misinterpreting its results. > It loks like a bug in some version of gcc. I tried to compile the > following program with version from Debian stable and unstable on ia64: >=20 > $ cat test.c > static void __attribute__((section(".exit.text"))) exit_pfm_fs(void) > { > return; > } > $ >=20 > With gcc 3.3.5: >=20 > $ readelf -a test.o | grep exit_ > 9: 0000000000000000 16 FUNC LOCAL DEFAULT 9 exit_pfm_fs > $ objdump -W test.o > ... > The section .debug_info contains: >=20 > Compilation Unit @ offset 0x0: > Length: 52 > Version: 2 > Abbrev Offset: 0 > Pointer Size: 8 > <0>: Abbrev Number: 1 (DW_TAG_compile_unit) > DW_AT_stmt_list : 0 > DW_AT_name : (indirect string, offset: 0x38): test.c > DW_AT_comp_dir : (indirect string, offset: 0x0): /home/eugen > DW_AT_producer : (indirect string, offset: 0xc): GNU C 3.3.5 > (Debian 1:3.3.5-13) > DW_AT_language : 1 (ANSI C) > <1><1d>: Abbrev Number: 2 (DW_TAG_subprogram) > DW_AT_name : (indirect string, offset: 0x2c): exit_pfm_fs > DW_AT_decl_file : 1 > DW_AT_decl_line : 2 > DW_AT_prototyped : 1 > DW_AT_low_pc : 0 > DW_AT_high_pc : 0x10 > DW_AT_frame_base : 1 byte block: 5c (DW_OP_reg12) > ... > $ >=20 > With gcc 4.1.2: >=20 > $ readelf -a t.o | grep exit_ > $ objdump -W t.o | grep exit_ > objdump: Error: No comp units in .debug_info section ?objdump: Error: No > comp units in .debug_info section ?$ >=20 >=20