|
From: Philippe W. <phi...@sk...> - 2011-10-27 22:24:36
|
> Well, the Fedora16/ppc64 box I had access to was freshly installed with F16 > alpha yesterday. I pulled valgrind from svn and built it and tried to run the > gdbserver tests. I don't know what's changed (since the gdbserver tests had run > quite well on Fedora the last I tried), but I had major problems. The testcases > either hung or failed the pre-req because gdb.step does not exist. sigh.... I suspect you might encounter two different problems. First the gdb.step that does not exist: -------------------------------------- 'make regtest' calls 'gdbserver_tests/make_local_links /path/to/gdb' make_local_links tries to extract the gdb version from the gdb --version first line. Then depending on the gdb version, the gdb.step file is created to indicate that gdb properly implements 'step command', otherwise, gdb.step is removed. gdb.step should always be created for gdb version >= 7.0, except on ARM where gdb version must be >= 7.1. So, if there is no gdb.step on fedora16/ppc64, it might be that the way make_local_links extracts the version does not work properly with the gdb on fedora16/ppc. Can you send me the result of gdb --version? Second the hanging tests: ------------------------- even if gdb.step is not created, that should just disable some tests. It should not create hanging tests. What I have often seen on ppc systems is that the standard visible gdb is a 32 bits gdb, which cannot debug the 64 bits executable. This can then cause the test to block. I just regained access to the gcc38 ppc gcc farm system. This is what I have on this system: philippe@ps3gccfarm:~/valgrind/trunk_untouched$ /usr/bin/gdb gdbserver_tests/t GNU gdb (GDB) 7.0.1-debian ..... "/home/philippe/valgrind/trunk_untouched/gdbserver_tests/t": not in executable format: File format not recognized (gdb) quit With a gdb I compiled myself in 64 bits: philippe@ps3gccfarm:~/valgrind/trunk_untouched$ /home/philippe/gdb/gdb-7.3.1/install/bin/gdb gdbserver_tests/t GNU gdb (GDB) 7.3.1 ... Reading symbols from /home/philippe/valgrind/trunk_untouched/gdbserver_tests/t...done. (gdb) I got another failure reason on this gcc38 system: vgdb relay application is taking a lock on a file to ensure it is the only one doing a relay with the Valgrind process using this file. For a yet not clear reason, the lock cannot be taken on gcc38 when the file is accessed through nfs. (if the file is local, the lock can be taken). I will do some more testing with an nfs tomorrow. But if this is your problem, the symptom will be vgdb writing the following error msg (and then failing) syscall failed: No locks available cannot acquire lock. The failure of vgdb will block the test (but the error msg above should be visible in one of the *.out test output file). If the blocking is not one of the above causes, then the output files of the tests (filtered and unfiltered, cfr previous mail) might allow me to investigate. Hope this helps Philippe |