From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26077 invoked by alias); 14 May 2013 21:11:40 -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 26068 invoked by uid 89); 14 May 2013 21:11:39 -0000 X-Spam-SWARE-Status: No, score=-7.4 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 14 May 2013 21:11:38 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4ELBaUl018277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 May 2013 17:11:36 -0400 Received: from [10.3.113.105] (ovpn-113-105.phx2.redhat.com [10.3.113.105]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r4ELBaqD023652; Tue, 14 May 2013 17:11:36 -0400 Message-ID: <5192A888.8090501@redhat.com> Date: Tue, 14 May 2013 21:11:00 -0000 From: Josh Stone User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: Thiago Manel CC: David Smith , "systemtap@sourceware.org" Subject: Re: problems with sched tapset on ubuntu precise 3.2.0 References: <518947C5.4020001@redhat.com> <51929D85.10508@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-q2/txt/msg00129.txt.bz2 On 05/14/2013 01:35 PM, Thiago Manel wrote: > I will try upgrading to a newer stap, thanks Josh. > > ... and, to finish this debug session I spotted a compiling problem (by > 'kernel.trace("sched_switch")' --poison-cache --vp 09), see below > [...] > /tmp/stapAJ6lCC/tracequery_kmod_20/tracequery_kmod_20.c:23:30: fatal > error: fs/xfs/xfs_types.h: No such file or directory Hmm, ok, the fact that this got up to kmod_20 means I was remembering incorrectly. We used to *try* all headers together, but then we did fall back to testing them individually. > Maybe I'm adding some noise but digging the commit history I saw this > (http://git.stealer.net/?p=systemtap.git;a=commitdiff;h=88637c31488f4987cc63c3f71263917dd98ca9cf) > --- which has the following description > > "Including xfs_types.h unconditionally on installations with no kernel > debuginfo would cause normal tracepoint processing to fail too. > * tapsets.cxx (tracepoint_extra_decls): Include xfs_types.h > only if we know the kernel source tree." Yes this commit looks related, but it's old enough that you should have it. (git describe --contains 88637c3 -> release-1.4~119) I think the one you need is commit 50b72692 (release-1.7~151^2~105). That limited the xfs_types.h hack to only tracepoint headers with "xfs" in their name. Also, the option for the source tree did show up in your command line as "-I/build/buildd/linux-3.2.0/debian/build/build-generic". I guess you don't actually have "fs/xfs/xfs_types.h" in that path? Do you even have /build/buildd/... at all? This may be tracepoint_builder::init_dw too eager to trust DW_AT_comp_dir...