Re: problems with sched tapset on ubuntu precise 3.2.0

[Josh Stone <jistone@redhat.com>]

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...