|
From: Philippe W. <phi...@sk...> - 2011-10-31 19:06:25
|
> 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). 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 ? |