[Bug gdb/27941] New: ppc gdb machine interface not returning or allowing set of FP registers

[Bug gdb/27941] New: ppc gdb machine interface not returning or allowing set of FP registers

[lkcl at lkcl dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=27941

            Bug ID: 27941
           Summary: ppc gdb machine interface not returning or allowing
                    set of FP registers
           Product: gdb
           Version: 9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: lkcl at lkcl dot net
  Target Milestone: ---

we have a fascinating obscure limitation of what is probably a previously
untested codepath: gdb mi2 for ppc remote automated execution of qemu being
used for extensive automated singlestep.

please note: this *might* turn out to be a bug in qemu-system-ppc64le not gdb.
a crossref to this bug will be raised if it is.

the background: a python-based "easy to read" ppc64 simulator is being
developed and needs a benchmark to compare against.  using pygdbmi, the idea is
to *co-simulate* the exact same program, first running one instruction under
remote mi2 control, then singlestep the python-based simulator, extract ALL
registers from both plus last known modified memory location, compare the two,
and report any discrepancies.  investigate, fix bug in simulator, restart,
repeat.

worked incredibly well (and incredibly slowly - one instruction per second)
right up until we tried setting and getting of ppc64 FPRs.

when reading the FPRs over remote mi2 to qemu the FPRs are reported to be ZERO.

when setting FPRs "-data-evaluate-expr $fp=0x3fe00000000000" and re-reading,
the contents are ZERO.

the only way to workaround this was, horror of horrors, to set
$vs0.v4_int32={0,0,0x%x,0x%x} instead, relying on a unique but fortunate
property of VSX registers being 25% mapped onto the FPRs.

*this workaround is successful* but is truly dreadful :)

along the way an additional experiment was carried out.  the exact same program
was loaded into qemu with MANUAL gdb remote (non-machine-interface mode) in the
"usual" way i.e. by a human typing the "normal" gdb commands at a tty.

here it was discovered that "$fp=1.0" will be successful.

info r $fp is also successful.

however what was NOT successful was "$fp=0x3fe0000000000".

attempts to try "$fp.raw=0xNnnnnnnnn" were also unsuccessful (syntax error)

the expected behaviour here is as follows:

1) in mi2 mode, set and get of FPRs to work, setting hexadecimal values WTHOUT
any kind of FP conversion or interference.

2) in standard mode, $fp0=0xNnnnn to be interpreted as a request to set the FPR
to the raw hexadecimal value.  the lack of warning and resultant data
corruption is the first bug here, the second bug is being unable to enter raw
hexadecimal values directly into the FPRs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.