|
From: Maynard J. <may...@us...> - 2011-10-18 15:12:28
|
Philippe Waroquiers wrote:
>> The regression tests on POWER7/SLES 11 SP1 (using Oct 6, 2011 SVN) actually compare quite favorably to Valgrind 3.6.1 on a POWER5
>> (POWER7 support did not yet exist in 3.6.1 timeframe). For reference, here are the results:
>
> The attached diff files also contains differences for mcbreak, but mcbreak is not in the below list ???
>> gdbserver_tests/mcinfcallRU (stderr)
>> gdbserver_tests/mcinfcallWSRU (stderr)
>> gdbserver_tests/mcinfcallWSRU (stderrB)
> These 3 failures+the mcbreak seems linked to problems to do an inferior function call.
Philippe,
The gdbserver tests actually run better on my POWER7/Fedora 16 box. With the patches applied for which I've recently opened bug reports (faultstatus bug #283709 and filter_gdb bug #284305), I only get one gdbserver test failure -- mcmain_pic. I went back to my SLES 11 SP1/POWER7 box where I was seeing the above gdbserver_tests failures and tried using the debugging tips in gdbserver_tests/README_DEVELOPERS to debug the mcbreak problem, but I couldn't get the breakpoints to set correctly. In both cases when trying to set breakpoints in t.c, I get the message:
No symbol table is loaded. Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n])
I tried both 'y' and 'n', but I get the same results either way. The valgrind process continues up to the point where I see the message "Petaouchnok sleep nr 15 out of 15 sleeping 5 seconds" and the gdb process just says "continuing", and then both processes are stuck there, and I have to quit gdb and ctl-C valgrind.
By the way, I was able to successfully run mcsigpass manually (one session for valgrind and one session for gdb) using mcsigpass.stdinB.gdb as input to the gdb session, so I *think* I'm running the two processes correctly in manual mode. Any idea what I'm doing wrong? I'm not versed in using gdbserver, so it's very possible I'm missing something.
Thanks.
-Maynard
>
[snip]
> Philippe
>
|