This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: "no match" semantic error for some existing probe points
- From: "Gui,Jian" <guij at cn dot ibm dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Roland McGrath <roland at redhat dot com>, systemtap at sources dot redhat dot com, "Frank Ch. Eigler" <fche at redhat dot com>
- Date: Wed, 01 Nov 2006 17:42:45 +0800
- Subject: Re: "no match" semantic error for some existing probe points
- References: <20061030205508.0F8C7180051@magilla.sf.frob.com> <orbqnr1wzf.fsf@lsd.ic.unicamp.br>
Alexandre Oliva wrote:
Indeed, but this is an inlined call of ptrace_disabled. What we're
missing is info about the clear_single_step() inlined call. However,
in my kernel source tree, clear_single_step is a macro, not a
function, so you won't get debug info for it without -g3 and, even
then, you may not get any line numbers whatsoever for the function
that does nothing but call a macro.
In 2.6.18.1, clear_single_step is defined as an inlined call in
arch/powerpc/kernel/ptrace.c (ppc64) or
arch/powerpc/kernel/ptrace.c (ppc32). Although it is also defined
as macro in arch/powerpc/kernel/traps.c, I think ptrace_disable is
using its inlined call definition.
I'm going to need preprocessed sources, a compilation command line and
a compiler version number in order to try to get more detailed info
and fix the compiler bug, if there is one.
Ideally, such info should be in a Systemtap bug report at
sources.redhat.com or bugzilla.redhat.com.
Thanks. I've opened bug 3441 for this and attached some data.
http://sourceware.org/bugzilla/show_bug.cgi?id=3441
Please let me know if more info is needed.
-Guijian