From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4885 invoked by alias); 8 Dec 2011 15:21:16 -0000 Received: (qmail 4873 invoked by uid 22791); 8 Dec 2011 15:21:14 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 08 Dec 2011 15:21:01 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1RYfmO-00053K-Pn from wade_farnsworth@mentor.com ; Thu, 08 Dec 2011 07:21:00 -0800 Received: from SVR-ORW-FEM-03.mgc.mentorg.com ([147.34.97.39]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Dec 2011 07:20:58 -0800 Received: from [172.30.7.122] (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.1.289.1; Thu, 8 Dec 2011 07:20:58 -0800 Message-ID: <4EE0D5D8.2030906@mentor.com> Date: Thu, 08 Dec 2011 19:24:00 -0000 From: Wade Farnsworth User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mark Wielaard CC: Subject: Re: Test suite results for ARM with uprobes References: <4EDE70F5.7000108@mentor.com> <1323262369.8528.57.camel@springer.wildebeest.org> In-Reply-To: <1323262369.8528.57.camel@springer.wildebeest.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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: 2011-q4/txt/msg00326.txt.bz2 Hi Mark, Thanks for your analysis! Mark Wielaard wrote: > On Tue, 2011-12-06 at 12:45 -0700, Wade Farnsworth wrote: [...] >> First, four tests are causing hangs, panics or other kernel errors. > > In general I found that arm kernels pre-3.0 (2.6.40 in fedora speak) > were somewhat unstable. There were lots of kprobe cleanups in 3.0. > Ah, yes. You did mention that previously. I'll see about retesting with something more recent. [...] >> FAIL: debugpath-good (eof) [This one puzzles me. I've built with >> CONFIG_DEBUG_INFO enabled and the build directory exists in >> /lib/modules/`uname -r`/build. Is there something else that I need to >> do to get systemtap access to the debug info?] > > It fails because: > spawn env SYSTEMTAP_DEBUGINFO_PATH=/lib/modules/2.6.37.6-yocto-standard+/build s > tap -e probe kernel.function("vfs_read") {} -wp2 > semantic error: missing arm kernel/module debuginfo under '/lib/modules/2.6.37.6 > -yocto-standard+/build' while resolving probe point kernel.function("vfs_read") > Pass 2: analysis failed. Try again with another '--vp 01' option. > FAIL: debugpath-good (eof) > > It PASSes for me with: > spawn env SYSTEMTAP_DEBUGINFO_PATH=/usr/lib/debug stap -e probe kernel.function( > "vfs_read") {} -wp2 > # probes > kernel.function("vfs_read@fs/read_write.c:306") /* pc=_stext+0x1445e0 */ /*<- k > ernel.function("vfs_read") */ > PASS: debugpath-good > > The debugpath.exp testcase does: > > # Guess where debuginfo is installed > if [file isdirectory /usr/lib/debug] { > set debuginfo_path "/usr/lib/debug" > } elseif [file isdirectory /lib/modules/$uname/build] { > set debuginfo_path "/lib/modules/$uname/build" > } else { > set debuginfo_path "/lib/modules/$uname" > } > > So, I guess it is guessing wrongly? > Hmm, I do have the debuginfo-enabled vmlinux in /lib/modules/2.6.37.6-yocto-standard+/build, which stap seems to otherwise be able to find. For some reason it seems to only occur when SYSTEMTAP_DEBUGINFO_PATH is used. I'll do some more digging. [...] > >> FAIL: inlinedvars-m32-O >> FAIL: inlinedvars-m32-O2 >> [line 1: expected "call (22,84)" >> Got " (84,22)"] > > That is interesting, it switches the numbers around? > It obviously doesn't run for me. It would be interesting to see the > debuginfo debug-dump of the created binary, the disassembly of function > "m" and the generated stap script C source code. Could you create a bug > report with that info in it? Done. http://sourceware.org/bugzilla/show_bug.cgi?id=13485 [...] > >> FAIL: sdt -O2 uprobe >> FAIL: sdt c89 uprobe >> FAIL: sdt c99 uprobe >> FAIL: sdt c99 -pedantic uprobe >> FAIL: sdt gnu99 uprobe >> FAIL: sdt gnu99 -pedantic uprobe >> FAIL: sdt c++98 uprobe >> FAIL: sdt c++98 -pedantic uprobe >> FAIL: sdt gnu++98 uprobe >> FAIL: sdt gnu++98 -pedantic uprobe >> FAIL: sdt c++0x uprobe >> FAIL: sdt c++0x -pedantic uprobe >> FAIL: sdt gnu++0x uprobe >> FAIL: sdt gnu++0x -pedantic uprobe >> [semantic error: unable to find local 'arg1' near pc 0x8408 in call1 >> /home/root/stuff/systemtap/testsuite/systemtap.base/sdt.c ( >> (alternatives: $a): identifier '$arg1' at >> /home/root/stuff/systemtap/testsuite/systemtap.base/sdt.stp:8:18.] >> >> FAIL: sdt_va_args base >> FAIL: sdt_va_args c89 >> FAIL: sdt_va_args c99 >> FAIL: sdt_va_args gnu99 >> FAIL: sdt_va_args c++98 >> FAIL: sdt_va_args gnu++98 >> FAIL: sdt_va_args c++0x >> FAIL: sdt_va_args gnu++0x >> [similar to the sdt failures above] > > I am unable to run these tests, but it would be interesting to see > debuginfo dump, disassembly and generated stap script C source for > these. The failure occurs before the C source is generated I have uploaded the other info to: http://dl.dropbox.com/u/40714612/stap-debug-files.tar.gz [...] >> FAIL: vta-test-m32-O >> FAIL: vta-test-m32-O2 >> [semantic error: failed to retrieve location attribute for local 'a' >> (dieoffset: 0x181): identifier '$a' at >> /home/root/stuff/systemtap/testsuite/systemtap.base/vta-test.stp:2:27] > > I cannot run this tests. It would be interesting to see the debuginfo > dump for the generated binary. Also in the tarball on dropbox. [...] > >> FAIL: buildok/seventeen.stp [semantic error: unable to find local >> 'nfs_program' near pc 0xc01bc714 in nfs_fsync_dir] > > This one does PASS for me. We should probably compare generated > debuginfo for our kernels. > Kernel debuginfo is also in the tarball. [...] >> FAIL: semok/config_number.stp [semantic error: probe point mismatch at >> position 0] > > This one PASSes for me. > What is CONFIG_NR_CPU set to for your kernel? > It is set to 2 for me. > CONFIG_SMP is not set, so CONFIG_NR_CPU doesn't exist in my config file. Maybe stap treats that as being equal to zero? I'll keep poking at the other failures. Thanks again! Regards, -Wade Farnsworth