From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17601 invoked by alias); 25 Jul 2011 10:04:19 -0000 Received: (qmail 17592 invoked by uid 22791); 25 Jul 2011 10:04:18 -0000 X-SWARE-Spam-Status: No, hits=-7.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 25 Jul 2011 10:04:03 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p6PA42mQ031595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Jul 2011 06:04:02 -0400 Received: from springer.wildebeest.org (ovpn-113-84.phx2.redhat.com [10.3.113.84]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p6PA40Xx002107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jul 2011 06:04:01 -0400 Received: by springer.wildebeest.org (Postfix, from userid 500) id BA515409D2; Mon, 25 Jul 2011 12:03:59 +0200 (CEST) Subject: Re: error to run systemtap in an ARM platform From: Mark Wielaard To: Zheng Da Cc: William Cohen , "Turgis, Frederic" , "systemtap@sourceware.org" In-Reply-To: References: <4E1F90A8.2080000@gmail.com> <1310722941.4510.5.camel@springer.wildebeest.org> <4E209C3F.6060806@gmail.com> <4E20A6EF.9010003@redhat.com> <4E20B11A.5020402@gmail.com> <13872098A06B02418CF379A158C0F1460162204601@dnce02.ent.ti.com> <4E243F49.9020706@redhat.com> <4E24831E.1000005@gmail.com> <4E249307.5050003@redhat.com> <4E249A82.8010404@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jul 2011 10:04:00 -0000 Message-ID: <1311588239.3322.26.camel@springer.wildebeest.org> Mime-Version: 1.0 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 X-SW-Source: 2011-q3/txt/msg00089.txt.bz2 On Sat, 2011-07-23 at 15:55 -0700, Zheng Da wrote: > Hello, >=20 > I'm still trying to fix the problem. > semantic error: failed to retrieve return value location for vfs_write > (/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/= chromeos-kernel-9999/fs/read_write.c): > identifier '$return' at read-write.stp:7:6 > source: if ($return > 0) { > ^ Is this the only probe for which return values aren't available or are there others? What is your full script for triggering this issue? > I'm pretty sure CONFIG_DEBUG_INFO is enabled, and in > /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/c= hromeos-kernel-9999/build/tegra2_seaboard, > a binary file vmlinux is 57MB. It should contain the debug information. Would you be able to upload this somewhere so we can inspect the debug information? This looks like it is just the kernel image, not the debuginfo, which is often bigger. You can see with stap -vvv what systemtap is using. e.g.: focused on module 'kernel' =3D [0x0xffffffff81000000, -0x0xffffffff81e64000, bias 0x0 file /usr/lib/debug/lib/modules/2.6.35.13-92.fc14.x86_64/vmlinux ELF machine |x86_64 (code 62) > How does systemtap use the debug information? When it compiles the > script, does it need to read the debug information from the kernel > image? or it needs to read the .obj files of the kernel? It processes the debug information (either in the vmlinux image itself or from a separate debuginfo file) to extract knowledge of where to find probe points, parameters, variables, return values and types. This is used during the translate pass to produce the stap module. So that it isn't necessary at runtime of the module (for this of course the version/arch of the debuginfo during translate time and the linux kernel at runtime should match). Cheers, Mark