This is the mail archive of the
frysk@sources.redhat.com
mailing list for the frysk project.
Re: Test result of utrace on PPC64(based on Fedoracore 6 Test 2 release).
- From: Wu Zhou <woodzltc at cn dot ibm dot com>
- To: Yong Zheng <zhengyo at cn dot ibm dot com>
- Cc: frysk at sourceware dot org, roland at redhat dot com
- Date: Thu, 17 Aug 2006 12:55:28 +0800
- Subject: Re: Test result of utrace on PPC64(based on Fedoracore 6 Test 2 release).
- References: <1155694227.2913.95.camel@YZ_X86_64>
Appended is the difference of gdb.sum for 32-bits testcases (the situation is similar with 64-bit
testcases). We made some initial analysis:
--- 32on64on64-2.6.17-1.2145_FC5-2006-08-14/gdb.sum 2006-08-14 22:40:00.000000000 -0400
+++ 32on64on64-2.6.17-1.2517.fc6-2006-08-14/gdb.sum 2006-08-14 04:18:07.000000000 -0400
.....
PASS: gdb.base/auxv.exp: info auxv on gcore-created dump
-PASS: gdb.base/auxv.exp: matching auxv data from live and gcore
+FAIL: gdb.base/auxv.exp: matching auxv data from live and gcore
Our Comments:
This regression is related to this output:
15 AT_PLATFORM String identifying platform 0xfa61fa89 <Address 0xfa61fa89 out of bounds>
which should be:
15 AT_PLATFORM String identifying platform 0xff9e54a5 "power5+"
I guess kernel 2.6.17-1.2517.fc6 has problem in generating the correct AT_PLATFORM for power5+, or
that gdb has difficulty in reading out the platform identifying string from the gcore-created dump.
-ERROR: internal buffer is full.
-UNRESOLVED: gdb.base/checkpoint.exp: info checkpoints with at least 600 checkpoints
+PASS: gdb.base/checkpoint.exp: info checkpoints with at least 600 checkpoints
Our Comments:
fc6 (or utrace) supports large numbers of checkpoints better?
-FAIL: gdb.base/fileio.exp: Open for write but no write permission returns EACCES
+PASS: gdb.base/fileio.exp: Open for write but no write permission returns EACCES
-FAIL: gdb.base/fileio.exp: Unlinking a file in a directory w/o write access returns EACCES
+PASS: gdb.base/fileio.exp: Unlinking a file in a directory w/o write access returns EACCES
Our Comments:
don't know why it fails on 2.6.17-1.2145_FC5?
-PASS: gdb.base/gcore.exp: corefile restored un-initialized array
-PASS: gdb.base/gcore.exp: corefile restored heap array
+FAIL: gdb.base/gcore.exp: corefile restored un-initialized array
+FAIL: gdb.base/gcore.exp: corefile restored heap array
-PASS: gdb.base/info-proc.exp: info proc mapping
+FAIL: gdb.base/info-proc.exp: info proc mapping
Our Comments: no comments at this time. :-)
-PASS: gdb.base/recurse.exp: continue to recurse (a = 9)
-PASS: gdb.base/recurse.exp: continue to recurse (a = 8)
-PASS: gdb.base/recurse.exp: continue to recurse (a = 7)
-PASS: gdb.base/recurse.exp: continue to recurse (a = 6)
-PASS: gdb.base/recurse.exp: continue to recurse (a = 5)
-PASS: gdb.base/recurse.exp: next over b = 0 in second instance
+FAIL: gdb.base/recurse.exp: continue to recurse (a = 9)
+FAIL: gdb.base/recurse.exp: continue to recurse (a = 8)
+FAIL: gdb.base/recurse.exp: continue to recurse (a = 7)
+FAIL: gdb.base/recurse.exp: continue to recurse (a = 6)
+FAIL: gdb.base/recurse.exp: continue to recurse (a = 5)
+FAIL: gdb.base/recurse.exp: next over b = 0 in second instance
-PASS: gdb.base/recurse.exp: continue to second instance watchpoint, first time
+FAIL: gdb.base/recurse.exp: continue to second instance watchpoint, first time
Our Comments:
2.6.17-1.2145_FC5 reports gdb is using hardware watchpoint. 2.6.17-1.2517.fc6 doesn't. Maybe
utrace don't implement commands GET_DEBUGREG and SET_DEBUGREG of ptrace for ppc64?
-FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler entry; performing step
+PASS: gdb.base/sigstep.exp: step on breakpoint, to handler entry; performing step
-FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler entry; performing next
+PASS: gdb.base/sigstep.exp: next on breakpoint, to handler entry; performing next
-FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler entry; performing continue
+PASS: gdb.base/sigstep.exp: continue on breakpoint, to handler entry; performing continue
Our comments: 2.6.17-1.2517.fc6 (utrace kernel) behaves better than 2.6.17-1.2145_FC5 (ptrace kernel).
-PASS: gdb.mi/mi-watch.exp: wp out of scope
+FAIL: gdb.mi/mi-watch.exp: wp out of scope (2)
-PASS: gdb.mi/mi2-watch.exp: wp out of scope
+FAIL: gdb.mi/mi2-watch.exp: wp out of scope (2)
Our comments: still watchpoint relevant. no further analysis yet.
-PASS: gdb.threads/gcore-thread.exp: corefile contains at least two threads
+FAIL: gdb.threads/gcore-thread.exp: corefile contains at least two threads
-PASS: gdb.threads/linux-dp.exp: philosopher is distinct: 2
+FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 2
-PASS: gdb.threads/manythreads.exp: stop threads 1
-PASS: gdb.threads/manythreads.exp: info threads
-PASS: gdb.threads/manythreads.exp: second continue
-PASS: gdb.threads/manythreads.exp: stop threads 2
+FAIL: gdb.threads/manythreads.exp: stop threads 1
+FAIL: gdb.threads/manythreads.exp: info threads
+FAIL: gdb.threads/manythreads.exp: second continue
+FAIL: gdb.threads/manythreads.exp: stop threads 2
-PASS: gdb.threads/schedlock.exp: thread 1 ran
+FAIL: gdb.threads/schedlock.exp: thread 1 ran (didn't run)
-PASS: gdb.threads/watchthreads.exp: watch args[0]
+FAIL: gdb.threads/watchthreads.exp: watch args[0]
-FAIL: gdb.threads/watchthreads.exp: threaded watch loop (timeout)
-PASS: gdb.threads/watchthreads.exp: first watchpoint on args[0] hit
+FAIL: gdb.threads/watchthreads.exp: threaded watch loop
+FAIL: gdb.threads/watchthreads.exp: first watchpoint on args[0] hit
Our comments:
main differences are in this aspect (multi-thread debugging), don't do any analysis yet.
@@ -335,7 +335,9 @@
PASS: gdb.base/bigcore.exp: grab pid
Yong Zheng wrote:
Hi all,
Fedora Core 6 Test 2 has been released on July 7, 2006. Based on it, we
do one thorough test on PPC64. The test consists of the following two
parts and we summarize what we have tested as follows, wishing it can be
helpful for you to get a picture of how utrace works on PPC64.
1. Gdb's test on the FC6 test 2 release
In this part, we build gdb and run gdb testsuite on PPC64 with the
kernel 2.6.17-1.2517(shipped with FC6 Test 2). As for comparison, we
also run gdb testsuite on kernel 2.6.17-1.2145(without utrace patched in
but with the original ptrace).
On each kernel, we run gdb testsuite twice: the first by compiling them
into 32bits ELF files and the second by compiling them into 64bits ELF
files. The test results are shown in the following tables:
Testcase 32on64on64(2.6.17-1.2145) 32on64on64(2.6.17-1.2517)
expected passes 10673 10660
unexpected failures 339(3.18%) 356(3.34%)
expected failures 40 40
known failures 59 59
unresolved testcases 15 14
untested testcases 5 4
unsupported tests 11 11
Testcase 64on64on64(2.6.17-1.2145) 64on64on64(2.6.17-1.2517)
expected passes 10684 10665
unexpected failures 392(3.67%) 409(3.835%)
expected failures 44 44
known failures 60 60
unresolved testcases 4 4
untested testcases 1 1
unsupported tests 12 14
Seen from the numbers in the above tables, the test results are very
encouraging. There're just only more 17 unexpected failures on the
kernel patched in utrace than on the kernel with the original ptrace!
If anyone think the detailed test results might be helpful, we're
willing to send the test results(including all test logs) to you.
2. utrace's testsuite on the FC6 test 2 release
As to utrace's testsuite, there are two test ways: one is to do the test
through building case into executable program; another is through
compiling case into kernel module.
If we choose the former test way, all testcases in ntrace package(you
can get it from roland's website:
http://people.redhat.com/roland/utrace/) work well, the kernel runs well
during and after the test. All seems to be good.
However, if you build testcase(for example, crash-suspend.c, also got
from the roland's website) into kernel module, insert the module and
then do the test, the kernel may crash once in a while.
Best regards
Yong Zheng