|
From: Julian S. <js...@ac...> - 2006-01-18 06:02:20
|
After a great deal of hacking (mostly by Cerion) the ppc64-linux port is coming to life. As of revisions 1541/5549, it fails 24 out of 185 regression tests on a PPC970 running YDL4.0. This puts it within hailing distance of the other three ports. Folks with ppc64-linux boxes might like to check out and give it a try. There will inevitably be breakage, and some testing at this stage would be no bad thing. Currently known deficiencies are: - there's something funny about stack unwinding I haven't figured out yet, causing stack traces that should be different to look the same. - function wrapping (but not intercepting) is broken. The ELF ppc64 ABI makes a difficult problem even harder, and I haven't got all the loose ends tied up yet. It may turn out that with this ABI, function wrapping cannot be made to work as robustly as on ELF x86/amd64/ppc32. - Lots of missing syscalls. As with the amd64 port, this port is fully biarch-capable and so a single build on a ppc64-linux box should be able to run 32-bit executables too. J == 185 tests, 18 stderr failures, 6 stdout failures ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/overlap (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/post-syscall (stdout) memcheck/tests/sigaltstack (stderr) memcheck/tests/sigprocmask (stderr) memcheck/tests/stack_changes (stdout) memcheck/tests/stack_changes (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/wrap5 (stdout) memcheck/tests/wrap5 (stderr) memcheck/tests/wrap6 (stdout) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/sem (stderr) |
|
From: Dave N. <dc...@us...> - 2006-01-18 21:25:10
|
I tried building this version on an IBM PPC970. uname -a: Linux elm3b148.beaverton.ibm.com 2.6.9-5.EL #1 SMP Wed Jan 5 19:23:58 EST 2005 ppc64 ppc64 ppc64 GNU/Linux elm3b148% gcc -v Reading specs from /usr/lib/gcc/ppc64-redhat-linux/3.4.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 --disable-libunwind-exceptions --enable-java-awt=gtk --host=ppc64-redhat-linux --build=ppc64-redhat-linux --target=ppc64-redhat-linux --with-cpu=default32 Thread model: posix gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.1) and I get the following errors building the test programs in helgrind/tests. Should these tests compile cleanly? make allok deadlock inherit race race2 readshared make[1]: Entering directory `/home/dcn/svn/1-18/helgrind/tests' if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -Winline -Wall -Wshadow -gstabs -m64 -Wno-long-long -Wdeclaration-after-statement -MT allok.o -MD -MP -MF ".deps/allok.Tpo" -c -o allok.o allok.c; \ then mv -f ".deps/allok.Tpo" ".deps/allok.Po"; else rm -f ".deps/allok.Tpo"; exit 1; fi /tmp/ccYznKU9.s: Assembler messages: /tmp/ccYznKU9.s:285: Error: can't resolve `main' {.opd section} - `.L.main' {.text section} /tmp/ccYznKU9.s:285: Error: expression too complex make[1]: *** [allok.o] Error 1 make[1]: Leaving directory `/home/dcn/svn/1-18/helgrind/tests' make: *** [check-am] Error 2 Julian Seward wrote: > Folks with ppc64-linux boxes might like to check out and give it > a try. There will inevitably be breakage, and some testing at > this stage would be no bad thing. > |
|
From: Julian S. <js...@ac...> - 2006-01-18 22:34:52
|
> and I get the following errors building the test programs in
> helgrind/tests. Should these tests compile cleanly?
>
> make allok deadlock inherit race race2 readshared
> make[1]: Entering directory `/home/dcn/svn/1-18/helgrind/tests'
> if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -Winline -Wall -Wshadow
> -gstabs -m64 -Wno-long-long -Wdeclaration-after-statement -MT allok.o
> -MD -MP -MF ".deps/allok.Tpo" -c -o allok.o allok.c; \
> then mv -f ".deps/allok.Tpo" ".deps/allok.Po"; else rm -f
> ".deps/allok.Tpo"; exit 1; fi
> /tmp/ccYznKU9.s: Assembler messages:
> /tmp/ccYznKU9.s:285: Error: can't resolve `main' {.opd section} -
> `.L.main' {.text section}
They should compile cleanly and indeed they have on our 970.
helgrind/allok.c is a completely vanilla small pthreads program.
Are you able to compile it by hand (gcc -m64 -o allok allok.c -lpthread) ?
J
|
|
From: Julian S. <js...@ac...> - 2006-01-19 03:25:02
|
On Wednesday 18 January 2006 23:41, Dave Nomura wrote: > I am able to compile with the simple gcc invocation that you've given > below. I did some experimentation with the gcc invocation generated by > make and it appears that it is the -gstabs that causes the problem. > > The assembler file around line 285 looks like:280 .long 0 > 281 .byte 0,0,0,1,128,1,0,1 > 282 .size main,.-.L.main > 283 .stabs "a:(10,20)",128,0,0,112 > 284 .stabs "b:(10,20)",128,0,0,120 > 285 .stabn 192,0,0,main-.L.main > 286 .stabn 224,0,0,.Lscope1-.L.main > > If I compare this to the same test program built in the 3.1.0 ppc32 > valgrind it looks like: > 256 .size main, .-main > 257 .stabs "a:(10,20)",128,0,0,8 > 258 .stabs "b:(10,20)",128,0,0,12 > 259 .stabn 192,0,0,main-main > 260 .stabn 224,0,0,.Lscope1-main > > I don't know enough about the assembler to know what this gibberish > means but the assembler seems to be complaining about > "main-.L.main" vs "main-main" That might be a bug in gcc's .stabs generation for ppc64. Shouldn't the first line be > 285 .stabn 192,0,0,.L.main-.L.main ? It doesn't sound unreasonable for the assembler to complain about having to compute the difference in addresses between two symbols in different sections. J |