|
From: Philippe W. <phi...@sk...> - 2014-04-03 19:27:48
|
On Thu, 2014-04-03 at 11:23 -0700, Carl E. Love wrote: Hello Carl, I am giving here and there below some comments. I am not at all sure what I give can help, but it will not do damage in any case :). > I working on porting the current Valgrind Power PC Big Endian code to > also support Power PC Little Endian code. I have seen numerous messages > where Valgrind says "Conditional jump or move depends on uninitialised > value". I am running gdb on the guest code trying to examine the V-bits > to see what bits/bytes are not valid. Unfortunately, from what I get > from Valgrind, it shows the bytes are all valid yet I get an error > message. I have put debug print statements thoughout the various > routines that fetch the V-bits to verify the endianess mode is Little > Endian. That seems to be fine. I am still trying to sort out how the > V-bit checking works, where and how it is done. Here is what I have done > to check the state of the bytes at the location of the conditional > branch. Please let me know if I am not accessing the V-bits correctly > or I am miss interpreting the output. Assuming I am doing things > correctly, where exactly in Valgrind does the Vbit test occur? I would > like to step through the code. I have found routines for > reading/writing the shadow bits in mc_translate.c but am still trying to > find where the actual test is done that generates the error. Thanks for > your help. > > Code > > x40ca0c4 <pthread_join+116> addi r26,r30,-30512 │ > │0x40ca0c8 <pthread_join+120> bl 0x40d2308 <__pthread_enable_asynccancel+8>│ > │0x40ca0cc <pthread_join+124> nop │ > B+>│0x40ca0d0 <pthread_join+128> cmpld cr7,r31,r26 │ > │0x40ca0d4 <pthread_join+132> mtlr r3 │ > │0x40ca0d8 <pthread_join+136> beq cr7,0x40ca1bc <pthread_join+364> │ > > > running with > valgrind --vgdb=yes --vgdb-shadow-registers=yes --vgdb-error=0 ./hg05_race2 When doing really lowlevel debugging, you might use --vgdb=full (which automatically activates -vex-iropt-register-updates=allregs-at-each-insn). It might maybe also help to disable all or most of the VEX optimisations using the various --vex-.... options. When you are stopped on a breakpoint with gdb+vgdb, you might maybe look at the generated code (containing the VA bits helper calls) by using monitor v.translate <addr> [<traceflags>] (same as vex tracing, but can be used interactively on precisely what you want when you want). > > When I give gdb "info reg" it shows the register, registers1 and registers2. Not sure what the resgisters2 > is all about I only see registers1 discussed in http://valgrind.org/docs/manual/mc-manual.html#mc-manual.machine > but we will print both for completeness. I believe that the register set shadow1 is used for V bits, while the register set shadow2 is used for origin tracking. BTW, have you tried with --track-origins=yes ? This might maybe give a hint ? > > Run to address 0x40ca0d0 and start poking around. Note, we get the error about > "Conditional jump or move depends on uninitialised value" at 0x40ca0d8. > > (gdb) p $r31 > $4 = 78508480 > (gdb) p $r31s1 > $5 = 0 > (gdb) p $r31s2 > $6 = 0 > (gdb) p $r26 > $7 = 67386896 > (gdb) p $r26s1 > $8 = 0 > (gdb) p $r26s2 > $9 = 0 > (gdb) p $r3 > $10 = 0 > (gdb) p $r3s1 > $11 = 0 > (gdb) p $r3s2 > $12 = 0 > > (gdb) p $cr > $14 = 0 > (gdb) p $crs1 > $15 = 0 > (gdb) p $crs2 > $16 = 0 > > So, it appeard that r26, r31 and the condition code register are > completely defined. > > 0x00000000040ca0d4 in pthread_join () from /lib64/libpthread.so.0 > 1: x/i $pc > => 0x40ca0d4 <pthread_join+132>: mtlr r3 > > (gdb) p $r3 > $17 = 0 > (gdb) p $r3s1 > $18 = 0 > (gdb) p $r3s2 > $19 = 0 > (gdb) p $lr > $20 = (void (*)()) 0x0 > (gdb) p $lrs1 > $21 = (void (*)()) 0x0 > (gdb) p $lrs2 > $22 = (void (*)()) 0x0 > (gdb) > > (gdb) si > 0x00000000040ca0d8 in pthread_join () from /lib64/libpthread.so.0 > 1: x/i $pc > => 0x40ca0d8 <pthread_join+136>: beq cr7,0x40ca1bc <pthread_join+364> > > (gdb) p $cr > $24 = 0 > (gdb) p $crs1s > $25 = 0 > (gdb) p $crs2 > $26 = 0 > > condition register bits are all zero so eq is not true > > 0x00000000040ca0d8 in pthread_join () from /lib64/libpthread.so.0 > 1: x/i $pc > => 0x40ca0d8 <pthread_join+136>: beq cr7,0x40ca1bc > <pthread_join+364> > > also get warning from other window > > ==25684== Conditional jump or move depends on uninitialised value(s) > ==25684== at 0x40CA0D8: pthread_join (in /usr/lib64/libpthread-2.18.90.so) > ==25684== by 0x10000847: main (hg05_race2.c:31) > ==25684== > ==25684== (action on error) vgdb me ... > > (gdb) p $cr > $27 = 0 > (gdb) p $crs1 > $28 = 0 > (gdb) p $crs2 > $29 = 0 > > So, if I understand this, the zero in crs1 and crs2 says all bytes (particularly byte 7) > are all defined yet I get an error?? So, where in Valgrind does the test happen? Need to > debug the code I guess. I think your understanding about the above is correct (i.e. that all bits are initiatialised and that no error should be reported). So, looks like a nasty bug. Philippe |