Re: [Valgrind-developers] Tests failing or blocking on fedora16/ppc-power7

[Maynard J. <may...@us...>]

On 10/31/2011 2:06 PM, Philippe Waroquiers wrote:
>
>> Actually, these tests run OK on F16, but fail on SLES 11 SP1. When running on
>> F16, the stdout and stderr output (both redirected to one file) show the
>> "hello world" and the "fun_set_me 1234" print outs. But I don't see either of
>> these when I run the same thing on SLES 11 SP1. I don't really know what to
>> look for to see where things go bad. I've attached both files in a tar file.
>> Thanks for your help!
>
> It looks like the inferior function call fails on S11 because gdb puts a break in
> a non-executable mapping of vgdb-test.
>
> On F16, to execute the function call, gdb puts a break at address 0x10000498,
> which is _start in vgdb-test.
> It then puts this address in the lr register, change the program counter to be
> the address of fun.
> And then everything works fine.
> --9441:1:aspacem ( 1) /home/mpj/vgdb-test
> ...
> --9441:1:aspacem 6: file 0010000000-001000ffff 65536 r-xT- d=0xfd01 i=406682 o=0
> (1)
> --9441:1:aspacem 7: file 0010010000-001001ffff 65536 rw--- d=0xfd01 i=406682 o=0
> (1)
>
> I tried the same test on the gcc farm PS3 ppc64/debian with gdb 7.3.1.
> It works similarly to the F16: it puts a break in _start (in the r-x mapped
> vgdb-test).
>
> On S11, gdb puts a break at address 0x10011010, which is also in vgdb-test.
> But it is in the "rw" mapping of vgdb-test, not the r-x mapping:
> --53993:1:aspacem ( 1) /home/mpj/temp/vgdb-test
> ...
> --53993:1:aspacem 4: file 0010000000-001000ffff 65536 r-x-- d=0xfd00 i=24314763
> o=0 (1)
> --53993:1:aspacem 5: file 0010010000-001001ffff 65536 rw--- d=0xfd00 i=24314763
> o=0 (1)
>
> I guess that the sig 11 is generated by Valgrind as it refuses to execute
> instruction in a non executable mapping.
>
>  From what I can see by reading gdb code, gdb derives the _start address purely
> from the executable/debugging
> information, without querying gdbserver.
> So, it might be a bug in gdb, rather than a bug in the gdbserver.
> Which version of gdb are you using on S11 ?
> It might be worth trying with a recent gdb (e.g. the same as what I tried on the
> PS3 : gdb 7.3.1).

The version of stock gdb for SLES 11 SP1 is 7.0.  I built valgrind and ran the 
testcases using a newer toolchain, including a 7.3 gdb, and got different 
(better?) results.  Of the three failing testcases I mentioned earlier, one of 
them passes, and two fail differently, but appear to be very minor failure 
symptoms -- stderrB.diff has the following extra line:
         +'import site' failed; use -v for traceback

Unfortunately, the gdbserver testsuite did not run to completion, since it hung 
on the mcinvokeWS testcase.  I just can't spend any more time on this now, but I 
really appreciate your help in digging into these issues.

Thanks.
-Maynard

>
> If it still fails, the best will be to compare the behaviour between the gdb
> 7.3.1 gdbserver and
> the Valgrind gdbserver on S11 :
> * do the "break + fun call" with gdb 7.3.1 + Valgrind, using -v -v -v -d -d -d
> to have full trace.
> * do the same with the gdb 7.3.1 gdbserver+trace, something like:
> gdbserver --debug --remote-debug :1234 vgdb-test
> in another window:
> gdb vgdb-test
> target remote :1234
> ... same as with Valgrind : break then continue then p fun(1234)
>
> This should allow to confirm my reading of the gdb code regarding getting the
> _start address.
>
> Let's hope this is a gdb bug, otherwise finding why gdb + Valgrind gdbserver
> can't agree on the address
> of _start will not be a piece of cake.
> Philippe
>
> NB: what about the main_pic on F16. Is this more clear ?
>