From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28491 invoked by alias); 7 Dec 2009 15:36:11 -0000 Received: (qmail 28482 invoked by uid 22791); 7 Dec 2009 15:36:10 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-vw0-f195.google.com (HELO mail-vw0-f195.google.com) (209.85.212.195) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Dec 2009 15:36:05 +0000 Received: by vws33 with SMTP id 33so1719761vws.27 for ; Mon, 07 Dec 2009 07:36:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.123.219 with SMTP id q27mr8555606vcr.5.1260200163629; Mon, 07 Dec 2009 07:36:03 -0800 (PST) Date: Mon, 07 Dec 2009 15:36:00 -0000 Message-ID: Subject: unresolved type-semantic error From: naresh kamboju To: systemtap@sources.redhat.com Cc: "Frank Ch. Eigler" , Masami Hiramatsu , David Smith , Dave Brolley , David Howells , ananth@in.ibm.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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: 2009-q4/txt/msg00815.txt.bz2 Hi, I have come across with semantic errors in the SystemTap testsuite while building test cases. /*************************************************************/ File: tapset/signal.stp /*************************************************************/ probe signal.handle =3D kernel.function("handle_signal") { sig =3D $sig sig_name =3D _signal_name($sig) . . // Check whether the signal is a User Mode or Kernel mode Signal. if (sinfo =3D=3D 0 && sig_code <=3D 0) sig_mode =3D "User Mode Signal" else if (sinfo >=3D 1) sig_mode =3D "Kernel Mode Signal" } probe signal.handle.return =3D kernel.function("handle_signal").return ? { retstr =3D returnstr(1) } /*************************************************************/ build log /*************************************************************/ semantic error: failed to retrieve return value location for copy_process(kernel/fork.c): identifier '$return' at /usr/local/arm/devel/share/systemtap/tapset/kprocess.stp:28:12 source: task =3D $return ^ semantic error: failed to retrieve return value location for do_execve(fs/exec.c): identifier '$return' at :78:13 source: errno =3D $return ^ semantic error: not accessible at this address (0x80025c5c): identifier '$sig' at /usr/local/arm/devel/share/systemtap/tapset/signal.stp:526:11 source: sig =3D $sig ^ semantic error: not accessible at this address (0x80025c5c): identifier '$sig' at :527:29 source: sig_name =3D _signal_name($sig) ^ semantic error: probe_1813 with unresolved type: identifier 'sig' at /usr/local/arm/devel/share/systemtap/tapset/signal.stp:526:5 source: sig =3D $sig ^ semantic error: probe_1813 with unresolved type: identifier 'sig' at process_test.stp:43:14 source: log(sprint(sig)) ^ semantic error: probe_1813 with unresolved type: identifier 'sprint' at :43= :7 source: log(sprint(sig)) ^ semantic error: probe_1813 with unresolved type: identifier 'log' at :43:3 source: log(sprint(sig)) ^ Pass 2: analyzed script: 11 probe(s), 16 function(s), 16 embed(s), 0 global(s) in 230usr/50sys/289real ms. Pass 2: analysis failed. Try again with another '--vp 01' option. Keeping temporary directory "/tmp/stapFqPOLz" /*************************************************************/ This symbol is not present in the Kernel #nm vmlinux | grep "handle_signal" << nothing related to handle_signal >> /*************************************************************/ I have made the following changes to Kernel make test work make global and Export: ---------------------------------------------------------------------------= --------- Index: b/arch/arm/kernel/signal.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- a/arch/arm/kernel/signal.c +++ b/arch/arm/kernel/signal.c @@ -584,8 +584,14 @@ struct arm_abi arm_abi =3D { .restart =3D __NR_restart_syscall }; +#if 0 static int handle_signal(unsigned long sig, siginfo_t *info, struct k_sigaction *ka, sigset_t *oldset, struct pt_regs *regs) +#else +#include +int handle_signal(unsigned long sig, siginfo_t *info, + struct k_sigaction *ka, sigset_t *oldset, struct pt_regs *regs) +#endif { int ret; @@ -621,6 +627,7 @@ static int handle_signal(unsigned long s return ret; } +EXPORT_SYMBOL(handle_signal); static void do_signal(struct pt_regs *regs) { /*************************************************************/ I can say that the above method is not the best way to fix the issues. I have notices much these kinds of issues almost 70+ test cases. I have tested with systemtap-0.9.5 =85 systemtap-1.0. All these are expected failures? If not, Do we need to fix these issues at SystemTap or Kernel side? Best regards Naresh Kamboju