|
From: Josef W. <Jos...@gm...> - 2012-07-23 22:20:28
|
Hi, [should have sent this email also to the mailing list; doing now...] Am 23.07.2012 23:43, schrieb Philippe Waroquiers: > On Mon, 2012-07-23 at 23:35 +0200, Josef Weidendorfer wrote: >> Hi Philippe, >> >> not sure this is a known shortcoming. I just chased down >> bug 303963, and tried to use vgdb to find the difference >> between behaviour of real hardware and VEX (for the >> over-complex PCMPxSTRx instruction). >> >> However, comparing flags after pcmpistri in vgdb single- >> stepping was not useful, as flags obviously were not >> changed. VEX does condition calculation lazily. Perhaps >> this should be done every time vgdb is asked for the >> flag register? > > Hello Josef, > > When GDB asks to examine a memory location or a register, GDB sends > a "read" packet to the Valgrind gdbserver, which then > gets the desired value from either memory or from the thread state > guest register. > So, if the register state in the thread is not up to date, > then Valgrind gdbsrv will not return the correct value to GDB. > > If the IR code is not computing the flags, it looks not possible > to have Valgrind gdbsrv computing it on demand > (at least, I do not see how to do it, or what VEX call to do to > compute these flags). I assume for amd64, that would be amd64g_calculate_rflags_all(...) (in VEX/priv/guest_amd64_helpers.c). However I am not sure if the VEX registers to use as parameters are fixed (if so, there would be no need to pass them all the time from generated code?). > So, we would need a way to force VEX to always compute these flags. > Maybe --vex-iropt-precise-memory-exns=yes can help for that ? That did not help, but "--vex-guest-max-insns=1" actually does! Thanks for helping me to think in the right direction. Should we add this hint to the documentation somewhere? Josef > > Philippe > > > |