https://bugs.kde.org/show_bug.cgi?id=360008
--- Comment #3 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
Some more info:
* As discussed in comment 2, the vs registers high parts should be described.
It is however not clear to me if these registers should always be reported
to GDB
or if they should be reported only depending on some hwcaps.
If that is the case, then some logic similar to 'have_avx()' in
valgrind-low-amd64.c should
be implemented, so as to choose an xml file that only reports the registers
present
in the currently used arch.
* On top of adding the xml file for the vs registers, I suspect that it will be
needed
to either fix or remove the regnum notation in s1 and s2 xml files:
in the x86 and amd64 xml files, either the regnum components were updated in
the s1 and s2
xml files, or the regnum components were removed.
I see that many xml files (e.g. for power64, but also e.g. for mips) have
kept the regnum
of the 'original non shadow' xml file. Having such regnum is for sure also
causing problems.
It might even be the main cause for the vr shadow registers being incorrect.
Finally, a few hints that can help investigating:
* in GDB, you can use the command
maint print remote-registers
to see the definition of registers as understood by gdb.
The columns 'Rmt Nr g/G Offset' are giving the protocol register number and
the
offset in the g/G packets.
* to examine directly the valgrind threads registers, you can do in gdb+vgdb:
mo v.set h
then
add-symbol-file <full path name of tool file> 0x38000000
Then e.g. to print a register of thread 1, you can from gdb do
(gdb) p /x vgPlain_threads[1].arch.vex.guest_GPR13
$2 = 0x0
(gdb) p /x vgPlain_threads[1].arch.vex_shadow1.guest_GPR13
$3 = 0x0
(gdb)
(all valgrind global variables can be examined once host visibility was
activated using
mo v.set h
--
You are receiving this mail because:
You are watching all bug changes.
