|
From: Uttam P. <ut...@us...> - 2006-01-09 21:17:59
|
Hi,
I'm new to the valgrind community. I recently did a complete
build of valgrind-3.1.0 release on a Power5 machine. After doing make
regtest I found total of 21 tests failure. These may be known or not, but
I just wanted to report them to the mailing list anyway.
1) Results on power5 platform,
== 174 tests, 18 stderr failures, 3 stdout failures
=================
memcheck/tests/badjump (stderr)
memcheck/tests/badjump2 (stderr)
memcheck/tests/leak-cycle (stderr)
memcheck/tests/leak-tree (stderr)
memcheck/tests/mempool (stderr)
memcheck/tests/partiallydefinedeq (stderr)
memcheck/tests/pointer-trace (stderr)
memcheck/tests/supp1 (stderr)
memcheck/tests/supp_unknown (stderr)
memcheck/tests/toobig-allocs (stderr)
memcheck/tests/xml1 (stderr)
massif/tests/toobig-allocs (stderr)
none/tests/faultstatus (stderr)
none/tests/fdleak_cmsg (stderr)
none/tests/mremap (stderr)
none/tests/ppc32/jm-insns (stdout)
none/tests/ppc32/jm-insns (stderr)
none/tests/ppc32/jm-vmx (stdout)
none/tests/ppc32/jm-vmx (stderr)
none/tests/ppc32/testVMX (stdout)
none/tests/ppc32/testVMX (stderr)
make: *** [regtest] Error 1
Enviornment:
Hardware: Power5 (with 8 8 processors)
OS: Linux elm3b149 2.6.5-7.97-pseries64.nm #1 SMP Thu Mar 31
10:55:11 PST 2005 ppc64 ppc64 ppc64 GNU/Linux (SLES9)
GCC: gcc -v
Reading specs
from /usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/specs
Configured with: ../configure --enable-threads=posix
--prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --enable-languages=c,c
++,f77,objc,java,ada
--disable-checking --libdir=/usr/lib --enable-libgcj
--with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit
--host=powerpc-suse-linux --build=powerpc-suse-linux
--target=powerpc-suse-linux
--enable-targets=powerpc64-suse-linux
--enable-biarch
Thread model: posix
gcc version 3.3.3 (SuSE Linux)
2) Results on power4 platform,
== 174 tests, 23 stderr failures, 4 stdout failures
=================
memcheck/tests/badjump (stderr)
memcheck/tests/badjump2 (stderr)
memcheck/tests/leak-cycle (stderr)
memcheck/tests/leak-tree (stderr)
memcheck/tests/mempool (stderr)
memcheck/tests/partiallydefinedeq (stderr)
memcheck/tests/pointer-trace (stderr)
memcheck/tests/stack_switch (stderr)
memcheck/tests/supp1 (stderr)
memcheck/tests/supp_unknown (stderr)
memcheck/tests/toobig-allocs (stderr)
memcheck/tests/xml1 (stderr)
massif/tests/toobig-allocs (stderr)
none/tests/faultstatus (stderr)
none/tests/fdleak_cmsg (stderr)
none/tests/mremap (stderr)
none/tests/ppc32/jm-insns (stdout)
none/tests/ppc32/jm-insns (stderr)
none/tests/ppc32/jm-vmx (stdout)
none/tests/ppc32/jm-vmx (stderr)
none/tests/ppc32/testVMX (stdout)
none/tests/ppc32/testVMX (stderr)
none/tests/shell (stdout)
none/tests/shell (stderr)
none/tests/shell_valid1 (stderr)
none/tests/shell_valid2 (stderr)
none/tests/shell_valid3 (stderr)
make: *** [regtest] Error 1
Enviornment:
Hardware: Power4+ (with 4 processors)
OS: Linux elm3b11 2.4.21-17.EL #1 SMP Thu Jul 8 19:31:00 EDT
2004 ppc64 ppc64 ppc64 GNU/Linux (RHEL3)
GCC: gcc -v
Reading specs
from /usr/lib/gcc-lib/ppc64-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-shared --enable-threads=posix --disable-checking
--with-system-zlib --enable-__cxa_atexit
--host=ppc64-redhat-linux --build=ppc64-redhat-linux
--target=ppc64-redhat-linux --with-cpu=default32
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-52)
Please let me know if I'm missing some piece of information to
mention
in this email.
Also, let me know (which somebody will) if this is not the right
forum
for this kind of information/questions.
Thanks,
Uttam
|
|
From: Cerion Armour-B. <ce...@op...> - 2006-01-10 00:10:28
|
On Monday 09 January 2006 22:20, Uttam Pawar wrote: > Hi, > > I'm new to the valgrind community. I recently did a > complete build of valgrind-3.1.0 release on a Power5 machine. After doing > make regtest I found total of 21 tests failure. These may be known or not, > but I just wanted to report them to the mailing list anyway. > > 1) Results on power5 platform, > == 174 tests, 18 stderr failures, 3 stdout failures > ================= > memcheck/tests/badjump (stderr) > memcheck/tests/badjump2 (stderr) > memcheck/tests/leak-cycle (stderr) > memcheck/tests/leak-tree (stderr) > memcheck/tests/mempool (stderr) > memcheck/tests/partiallydefinedeq (stderr) > memcheck/tests/pointer-trace (stderr) > memcheck/tests/supp1 (stderr) > memcheck/tests/supp_unknown (stderr) > memcheck/tests/toobig-allocs (stderr) > memcheck/tests/xml1 (stderr) > massif/tests/toobig-allocs (stderr) > none/tests/faultstatus (stderr) > none/tests/fdleak_cmsg (stderr) > none/tests/mremap (stderr) > none/tests/ppc32/jm-insns (stdout) > none/tests/ppc32/jm-insns (stderr) > none/tests/ppc32/jm-vmx (stdout) > none/tests/ppc32/jm-vmx (stderr) > none/tests/ppc32/testVMX (stdout) > none/tests/ppc32/testVMX (stderr) > > make: *** [regtest] Error 1 > > Enviornment: > Hardware: Power5 (with 8 8 processors) > OS: Linux elm3b149 2.6.5-7.97-pseries64.nm #1 SMP Thu Mar > 31 10:55:11 PST 2005 ppc64 ppc64 ppc64 GNU/Linux (SLES9) GCC: gcc -v > Reading specs > from /usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/specs > Configured with: ../configure --enable-threads=posix > --prefix=/usr > --with-local-prefix=/usr/local --infodir=/usr/share/info > --mandir=/usr/share/man --enable-languages=c,c > ++,f77,objc,java,ada > --disable-checking --libdir=/usr/lib --enable-libgcj > --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib > --with-system-zlib --enable-shared --enable-__cxa_atexit > --host=powerpc-suse-linux --build=powerpc-suse-linux > --target=powerpc-suse-linux > --enable-targets=powerpc64-suse-linux > --enable-biarch > Thread model: posix > gcc version 3.3.3 (SuSE Linux) > > > > 2) Results on power4 platform, > > == 174 tests, 23 stderr failures, 4 stdout failures > ================= > memcheck/tests/badjump (stderr) > memcheck/tests/badjump2 (stderr) > memcheck/tests/leak-cycle (stderr) > memcheck/tests/leak-tree (stderr) > memcheck/tests/mempool (stderr) > memcheck/tests/partiallydefinedeq (stderr) > memcheck/tests/pointer-trace (stderr) > memcheck/tests/stack_switch (stderr) > memcheck/tests/supp1 (stderr) > memcheck/tests/supp_unknown (stderr) > memcheck/tests/toobig-allocs (stderr) > memcheck/tests/xml1 (stderr) > massif/tests/toobig-allocs (stderr) > none/tests/faultstatus (stderr) > none/tests/fdleak_cmsg (stderr) > none/tests/mremap (stderr) > none/tests/ppc32/jm-insns (stdout) > none/tests/ppc32/jm-insns (stderr) > none/tests/ppc32/jm-vmx (stdout) > none/tests/ppc32/jm-vmx (stderr) > none/tests/ppc32/testVMX (stdout) > none/tests/ppc32/testVMX (stderr) > none/tests/shell (stdout) > none/tests/shell (stderr) > none/tests/shell_valid1 (stderr) > none/tests/shell_valid2 (stderr) > none/tests/shell_valid3 (stderr) > > make: *** [regtest] Error 1 > > Enviornment: > Hardware: Power4+ (with 4 processors) > OS: Linux elm3b11 2.4.21-17.EL #1 SMP Thu Jul 8 19:31:00 > EDT 2004 ppc64 ppc64 ppc64 GNU/Linux (RHEL3) > GCC: gcc -v > Reading specs > from /usr/lib/gcc-lib/ppc64-redhat-linux/3.2.3/specs > Configured with: ../configure --prefix=/usr > --mandir=/usr/share/man --infodir=/usr/share/info > --enable-shared --enable-threads=posix --disable-checking > --with-system-zlib --enable-__cxa_atexit > --host=ppc64-redhat-linux --build=ppc64-redhat-linux > --target=ppc64-redhat-linux --with-cpu=default32 > Thread model: posix > gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-52) > > > Please let me know if I'm missing some piece of information > to mention in this email. > > Also, let me know (which somebody will) if this is not the > right forum for this kind of information/questions. You've got the right place, and it's great you're testing, but as J asked in reply to yr last post (i guess yr not subscribed): On Friday 06 January 2006 22:42, Julian Seward wrote: > Thanks. Most of these are harmless - they happen on a PPC970 box > too. We should improve our regression test mechanism so it only > reports a failure when there really is one, but that's not as simple > as it sounds. > > > none/tests/ppc32/jm-vmx (stdout) > > none/tests/ppc32/jm-vmx (stderr) > > none/tests/ppc32/testVMX (stdout) > > none/tests/ppc32/testVMX (stderr) > > These are VMX (Altivec) tests. I presume they failed because POWER5 > doesn't support Altivec (right?) > > > none/tests/ppc32/jm-insns (stdout) > > none/tests/ppc32/jm-insns (stderr) > > These should not fail -- tests of the basic integer instruction set. > Can you send > > none/tests/ppc32/jm-insns.stdout.diff and > none/tests/ppc32/jm-insns.stderr.diff > > so we can see why they failed. > > J |
|
From: Uttam P. <ut...@us...> - 2006-01-10 00:41:10
Attachments:
jm-insns.stdout.diff
|
Hi Thanks for the reply. > > You've got the right place, and it's great you're testing, but as J asked in > reply to yr last post (i guess yr not subscribed): Initially my subscribe request/response email bounced back as a spam. That's why I never received an email from Julian, till this message. But now I've completed the subscribe procedure successfully. > > On Friday 06 January 2006 22:42, Julian Seward wrote: > > Thanks. Most of these are harmless - they happen on a PPC970 box > > too. We should improve our regression test mechanism so it only > > reports a failure when there really is one, but that's not as simple > > as it sounds. > > > > > none/tests/ppc32/jm-vmx (stdout) > > > none/tests/ppc32/jm-vmx (stderr) > > > none/tests/ppc32/testVMX (stdout) > > > none/tests/ppc32/testVMX (stderr) > > > > These are VMX (Altivec) tests. I presume they failed because POWER5 > > doesn't support Altivec (right?) You are right. > > > > > none/tests/ppc32/jm-insns (stdout) > > > none/tests/ppc32/jm-insns (stderr) > > > > These should not fail -- tests of the basic integer instruction set. > > Can you send > > > > none/tests/ppc32/jm-insns.stdout.diff and > > none/tests/ppc32/jm-insns.stderr.diff > > > > so we can see why they failed. Strangely, these 2 tests did pass on a PPC970, altivec supported machine but failed on power4 and power5 platform. $ cat none/tests/ppc32/jm-insns.stderr.diff *** jm-insns.stderr.exp 2005-11-25 04:36:08.000000000 -0800 --- jm-insns.stderr.out 2006-01-06 14:07:49.000000000 -0800 *************** *** 1 **** --- 2,18 ---- + disInstr(ppc32): unhandled instruction: 0x........ + primary 31(0x........), secondary 206(0x........) + Your program just tried to execute an instruction that Valgrind + did not recognise. There are two possible reasons for this. + 1. Your program has a bug and erroneously jumped to a non-code + location. If you are running Memcheck and you just saw a + warning about a bad jump, it's probably your program's fault. + 2. The instruction is legitimate but Valgrind doesn't handle it, + i.e. it's Valgrind's fault. If you think this is the case or + you are not sure, please let us know. + Either way, Valgrind will now raise a SIGILL signal which will + probably kill your program. + + Process terminating with default action of signal 4 (SIGILL) + Illegal opcode at address 0x........ + at 0x........: build_viargs_table (in /home/pawar/valgrind-3.1.0/none/tests/ppc32/jm-insns) + by 0x........: main (in /home/pawar/valgrind-3.1.0/none/tests/ppc32/jm-insns) 2) File "none/tests/ppc32/jm-insns.stdout.diff" is quite large, so sending as an attachment with this email. Thanks, Uttam |
|
From: Cerion Armour-B. <ce...@op...> - 2006-01-10 09:37:26
|
On Tuesday 10 January 2006 01:43, Uttam Pawar wrote:
...
> > > > none/tests/ppc32/jm-insns (stdout)
> > > > none/tests/ppc32/jm-insns (stderr)
> > >
> > > These should not fail -- tests of the basic integer instruction set.
> > > Can you send
> > >
> > > none/tests/ppc32/jm-insns.stdout.diff and
> > > none/tests/ppc32/jm-insns.stderr.diff
> > >
> > > so we can see why they failed.
>
> Strangely, these 2 tests did pass on a PPC970, altivec supported machine
> but failed on power4 and power5 platform.
Not so strange - we developed on a ppc970 :-)
> $ cat none/tests/ppc32/jm-insns.stderr.diff
>
> *** jm-insns.stderr.exp 2005-11-25 04:36:08.000000000 -0800
> --- jm-insns.stderr.out 2006-01-06 14:07:49.000000000 -0800
> ***************
> *** 1 ****
> --- 2,18 ----
> + disInstr(ppc32): unhandled instruction: 0x........
> + primary 31(0x........), secondary 206(0x........)
> + Your program just tried to execute an instruction that Valgrind
> + did not recognise. There are two possible reasons for this.
> + 1. Your program has a bug and erroneously jumped to a non-code
> + location. If you are running Memcheck and you just saw a
> + warning about a bad jump, it's probably your program's fault.
> + 2. The instruction is legitimate but Valgrind doesn't handle it,
> + i.e. it's Valgrind's fault. If you think this is the case or
> + you are not sure, please let us know.
> + Either way, Valgrind will now raise a SIGILL signal which will
> + probably kill your program.
> +
> + Process terminating with default action of signal 4 (SIGILL)
> + Illegal opcode at address 0x........
> + at 0x........: build_viargs_table (in
> /home/pawar/valgrind-3.1.0/none/tests/ppc32/jm-insns) + by 0x........:
> main (in /home/pawar/valgrind-3.1.0/none/tests/ppc32/jm-insns)
Ok, it's a missing instruction.
Hmm - you're not getting the hex printouts...
Can you change VEX/priv/guest-ppc/toIR.c thusly:
vex_printf("disInstr(ppc): unhandled instruction: "
- "0x%x\n", theInstr);
+ "%u\n", theInstr);
Rebuild, run the test, and repost none/tests/ppc32/jm-insns.stderr.diff
- To run just that one test (from dir valgrind-3.1.0):
$ perl ./tests/vg_regtest ./none/tests/ppc32/jm-insns
> 2) File "none/tests/ppc32/jm-insns.stdout.diff" is quite large, so sending
> as an attachment with this email.
This is indicating no output at all by valgrind - ignore until we solve the
missing insn problem.
Thanks,
Cerion
|
|
From: Uttam P. <ut...@us...> - 2006-01-10 20:57:39
|
Hi Cerion,
> Not so strange - we developed on a ppc970 :-)
>
> Ok, it's a missing instruction.
> Hmm - you're not getting the hex printouts...
> Can you change VEX/priv/guest-ppc/toIR.c thusly:
>
> vex_printf("disInstr(ppc): unhandled instruction: "
> - "0x%x\n", theInstr);
> + "%u\n", theInstr);
>
> Rebuild, run the test, and repost none/tests/ppc32/jm-insns.stderr.diff
> - To run just that one test (from dir valgrind-3.1.0):
> $ perl ./tests/vg_regtest ./none/tests/ppc32/jm-insns
With the suggested change (in file VEX/priv/guest-ppc32/toIR.c),
building and re-running that one test we get following
(jm-insns.stderr.diff output)
$ cat none/tests/ppc32/jm-insns.stderr.diff
*** jm-insns.stderr.exp 2005-11-25 04:36:08.000000000 -0800
--- jm-insns.stderr.out 2006-01-10 12:47:26.000000000 -0800
***************
*** 1 ****
--- 2,22 ----
+ disInstr(ppc32): unhandled instruction: 2080393422
+ primary 31(0x........), secondary 206(0x........)
+ disInstr(ppc32): instr: 0111 1100 0000 0000 0100 1000 1100 1110
+ disInstr(ppc32): opcode1: 011111
+ disInstr(ppc32): opcode2: 0011001110
+
+ Your program just tried to execute an instruction that Valgrind
+ did not recognise. There are two possible reasons for this.
+ 1. Your program has a bug and erroneously jumped to a non-code
+ location. If you are running Memcheck and you just saw a
+ warning about a bad jump, it's probably your program's fault.
+ 2. The instruction is legitimate but Valgrind doesn't handle it,
+ i.e. it's Valgrind's fault. If you think this is the case or
+ you are not sure, please let us know.
+ Either way, Valgrind will now raise a SIGILL signal which will
+ probably kill your program.
+
+ Process terminating with default action of signal 4 (SIGILL)
+ Illegal opcode at address 0x........
+ at 0x........: build_viargs_table (in /home/pawar/valgrind-3.1.0/none/tests/ppc32/jm-insns)
+ by 0x........: main (in /home/pawar/valgrind-3.1.0/none/tests/ppc32/jm-insns)
Also, I noticed that, after making the change to toIR.c file, I'd to clean the directory with
make clean to rebuild libvex.a (toIR.o). Without that, toIR.o wouldn't get rebuild. And the test
result would be same as the previous one. Is it the known problem?
Thanks,
Uttam
|
|
From: Cerion Armour-B. <ce...@op...> - 2006-01-11 13:21:13
|
On Tuesday 10 January 2006 22:00, Uttam Pawar wrote: ... > + Process terminating with default action of signal 4 (SIGILL) > + Illegal opcode at address 0x........ > + at 0x........: build_viargs_table (in Cancel those last requests - I missed this. This is a problem of jm-insns, not of valgrind - the test always gets built with HAS_ALTIVEC defined, so we get altivec insns in the executable... will add to my todo list... > Also, I noticed that, after making the change to toIR.c file, I'd to clean > the directory with make clean to rebuild libvex.a (toIR.o). Without that, > toIR.o wouldn't get rebuild. And the test result would be same as the > previous one. Is it the known problem? Yes, the build system is not quite there... Cheers, Cerion |
|
From: Cerion Armour-B. <ce...@op...> - 2006-01-11 12:51:28
|
On Tuesday 10 January 2006 22:00, Uttam Pawar wrote:
> Hi Cerion,
>
> > Not so strange - we developed on a ppc970 :-)
> >
> >
> > Ok, it's a missing instruction.
> > Hmm - you're not getting the hex printouts...
> > Can you change VEX/priv/guest-ppc/toIR.c thusly:
> >
> > vex_printf("disInstr(ppc): unhandled instruction: "
> > - "0x%x\n", theInstr);
> > + "%u\n", theInstr);
> >
> > Rebuild, run the test, and repost none/tests/ppc32/jm-insns.stderr.diff
> > - To run just that one test (from dir valgrind-3.1.0):
> > $ perl ./tests/vg_regtest ./none/tests/ppc32/jm-insns
>
> With the suggested change (in file VEX/priv/guest-ppc32/toIR.c),
> building and re-running that one test we get following
> (jm-insns.stderr.diff output)
> $ cat none/tests/ppc32/jm-insns.stderr.diff
> *** jm-insns.stderr.exp 2005-11-25 04:36:08.000000000 -0800
> --- jm-insns.stderr.out 2006-01-10 12:47:26.000000000 -0800
> ***************
> *** 1 ****
> --- 2,22 ----
> + disInstr(ppc32): unhandled instruction: 2080393422
Ok, so 2080393422 == 0x7c0048ce == lvx v0,r0,r9 == altivec load
I though altivec wasn't generated on these platforms...
Can you post cat /proc/cpuinfo please?
Can you also run valgrind on the test with -d:
$ path_to_valgrind3_1_0 -d ./none/tests/ppc32/jm_insns
and post the debug line after ":main Get hardware capabilities ..."
Thanks,
Cerion
|
|
From: Cerion Armour-B. <ce...@op...> - 2006-01-11 18:43:53
|
On Wednesday 11 January 2006 19:24, Uttam Pawar wrote: > Hi Cerion, > > > Ok, so 2080393422 == 0x7c0048ce == lvx v0,r0,r9 == altivec load > > This is little off-topic question but, how did you decode 0x7c0048ce > into lvx v0,r0,r9? Is there any general receipe for doing this for ppc > platform? I don't know how others do it, but i did this: create xyz.s: .text nop nop gcc -c xyz.s hexedit xyz.o - replace first 600000 (ppc nop) with 7c0048ce objdump -d zzz.o ... 00000000 <.text>: 0: 7c 00 48 ce lvx v0,r0,r9 Anyone else out there got an easier way? Cerion |
|
From: Stephen M.
|
>>>>> "CA-B" == Cerion Armour-Brown <ce...@op...> writes: CA-B> On Wednesday 11 January 2006 19:24, Uttam Pawar wrote: UP> This is little off-topic question but, how did you decode UP> 0x7c0048ce into lvx v0,r0,r9? Is there any general receipe for UP> doing this for ppc platform? CA-B> I don't know how others do it, but i did this: CA-B> create xyz.s: CA-B> gcc -c xyz.s CA-B> hexedit xyz.o CA-B> objdump -d zzz.o CA-B> Anyone else out there got an easier way? Along the same lines, but more automated: % ./dump-insn-ppc.zsh 7c0048ce 0: 7c 00 48 ce lvx v0,r0,r9 % cat dump-insn-ppc.zsh #!/bin/zsh objdump -b binary -m powerpc -EB -D \ =(perl -e 'print pack "N", hex $ARGV[0]' $1) | tail +7 The version of objdump I'm using doesn't like to read from a pipe for some reason, but =(...) is a handy zsh feature that automatically creates and removes a temporary file. The "-EB" (big endian) is needed because I'm actually running this on an x86 (using the Debian "binutils-multiarch" package, a version compiled with support for a whole bunch of architectures besides your native one). -- Stephen |
|
From: Cerion Armour-B. <ce...@op...> - 2006-01-12 09:30:48
|
On Wednesday 11 January 2006 23:29, Stephen McCamant wrote: > >>>>> "CA-B" == Cerion Armour-Brown <ce...@op...> writes: > > CA-B> On Wednesday 11 January 2006 19:24, Uttam Pawar wrote: > UP> This is little off-topic question but, how did you decode > UP> 0x7c0048ce into lvx v0,r0,r9? Is there any general receipe for > UP> doing this for ppc platform? > > CA-B> I don't know how others do it, but i did this: > CA-B> create xyz.s: > CA-B> gcc -c xyz.s > CA-B> hexedit xyz.o > CA-B> objdump -d zzz.o > > CA-B> Anyone else out there got an easier way? > > Along the same lines, but more automated: > > % ./dump-insn-ppc.zsh 7c0048ce > 0: 7c 00 48 ce lvx v0,r0,r9 > % cat dump-insn-ppc.zsh > #!/bin/zsh > objdump -b binary -m powerpc -EB -D \ > =(perl -e 'print pack "N", hex $ARGV[0]' $1) | tail +7 Nice, thanks Stephen! Cerion |