bwlp/qemu.git/gdb-xml, branch master

gdb-xml: Fix size of EFER register on i386 architecture when debugged by GDB

2022-11-06T08:48:26+00:00

Before this commit, there were contradictory descriptions about size of EFER register. Line 113 says the size is 8 bytes. Line 129 says the size is 4 bytes. As a result, when GDB is debugging an OS running on QEMU, the GDB cannot read 'g' packets correctly. This 'g' packet transmits values of each registers of machine emulated by QEMU to GDB. QEMU, the packet sender, assign 4 bytes for EFER in 'g' packet based on the line 113. GDB, the packet receiver, extract 8 bytes for EFER in 'g' packet based on the line 129. Therefore, all registers located behind EFER in 'g' packet has been shifted 4 bytes in GDB. After this commit, GDB can read 'g' packets correctly. Signed-off-by: TaiseiIto Message-Id: Signed-off-by: Paolo Bonzini

target/riscv: remove fixed numbering from GDB xml feature files

2022-09-26T21:04:38+00:00

The fixed register numbering in the various GDB feature files for RISC-V only exists because these files were originally copied from the GDB source tree. However, the fixed numbering only exists in the GDB source tree so that GDB, when it connects to a target that doesn't provide a target description, will use a specific numbering scheme. That numbering scheme is designed to be compatible with the first versions of QEMU (for RISC-V), that didn't send a target description, and relied on a fixed numbering scheme. Because of the way that QEMU manages its target descriptions, recording the number of registers in each feature, and just relying on GDB's numbering starting from 0, then I propose that we remove all the fixed numbering from the RISC-V feature xml files, and just rely on the standard numbering scheme. Plenty of other targets manage their xml files this way, e.g. ARM, AArch64, Loongarch, m68k, rx, and s390. Signed-off-by: Andrew Burgess Acked-by: Alistair Francis Reviewed-by: Palmer Dabbelt Message-Id: <6069395f90e6fc24dac92197be815fedf42f5974.1661934573.git.aburgess@redhat.com> Signed-off-by: Alistair Francis

target/riscv: remove fflags, frm, and fcsr from riscv-*-fpu.xml

2022-09-26T21:04:38+00:00

While testing some changes to GDB's handling for the RISC-V registers fcsr, fflags, and frm, I spotted that QEMU includes these registers twice in the target description it sends to GDB, once in the fpu feature, and once in the csr feature. Right now things basically work OK, QEMU maps these registers onto two different register numbers, e.g. fcsr maps to both 68 and 73, and GDB can use either of these to access the register. However, GDB's target descriptions don't really work this way, each register should appear just once in a target description, mapping the register name onto the number GDB should use when accessing the register on the target. Duplicate register names actually result in duplicate registers on the GDB side, however, as the registers have the same name, the user can only access one of these registers. Currently GDB has a hack in place, specifically for RISC-V, to spot the duplicate copies of these three registers, and hide them from the user, ensuring the user only ever sees a single copy of each. In this commit I propose fixing this issue on the QEMU side, and in the process, simplify the fpu register handling a little. I think we should, remove fflags, frm, and fcsr from the two (32-bit and 64-bit) fpu feature xml files. These files will only contain the 32 core floating point register f0 to f31. The fflags, frm, and fcsr registers will continue to be advertised in the csr feature as they currently are. With that change made, I will simplify riscv_gdb_get_fpu and riscv_gdb_set_fpu, removing the extra handling for the 3 status registers. Signed-off-by: Andrew Burgess Reviewed-by: Alistair Francis Message-Id: <0fbf2a5b12e3210ff3867d5cf7022b3f3462c9c8.1661934573.git.aburgess@redhat.com> Signed-off-by: Alistair Francis

target/loongarch: Update loongarch-fpu.xml

2022-08-05T17:02:40+00:00

Rename loongarch-fpu64.xml to loongarch-fpu.xml and update loongarch-fpu.xml to match upstream GDB [1] [1]:https://github.com/bminor/binutils-gdb/blob/master/gdb/features/loongarch/fpu.xml Signed-off-by: Song Gao Reviewed-by: Richard Henderson Acked-by: Alex Bennée Message-Id: <20220805033523.1416837-5-gaosong@loongson.cn>

target/loongarch: update loongarch-base64.xml

2022-08-05T17:02:40+00:00

Update loongarch-base64.xml to match the upstream GDB [1]. [1]:https://github.com/bminor/binutils-gdb/blob/master/gdb/features/loongarch/base64.xml Reviewed-by: Richard Henderson Signed-off-by: Song Gao Acked-by: Alex Bennée Message-Id: <20220805033523.1416837-4-gaosong@loongson.cn>

target/loongarch: Fix GDB get the wrong pc

2022-08-05T17:02:40+00:00

GDB LoongArch add a register orig_a0, see the base64.xml [1]. We should add the orig_a0 to match the upstream GDB. [1]: https://github.com/bminor/binutils-gdb/blob/master/gdb/features/loongarch/base64.xml Signed-off-by: Song Gao Reviewed-by: Richard Henderson Acked-by: Alex Bennée Message-Id: <20220805033523.1416837-2-gaosong@loongson.cn>

target/loongarch: Add gdb support.

2022-06-06T18:14:13+00:00

Signed-off-by: Xiaojuan Yang Signed-off-by: Song Gao Reviewed-by: Richard Henderson Message-Id: <20220606124333.2060567-42-yangxiaojuan@loongson.cn> Signed-off-by: Richard Henderson

target/arm: Advertise MVE to gdb when present

2021-11-02T18:14:55+00:00

Cortex-M CPUs with MVE should advertise this fact to gdb, using the org.gnu.gdb.arm.m-profile-mve XML feature, which defines the VPR register. Presence of this feature also tells gdb to create pseudo-registers Q0..Q7, so we do not need to tell gdb about them separately. Note that unless you have a very recent GDB that includes this fix: http://patches-tcwg.linaro.org/patch/58133/ gdb will mis-print the individual fields of the VPR register as zero (but showing the whole thing as hex, eg with "print /x $vpr" will give the correct value). Signed-off-by: Peter Maydell Reviewed-by: Richard Henderson Reviewed-by: Philippe Mathieu-Daudé Message-Id: <20211101160814.5103-1-peter.maydell@linaro.org> Signed-off-by: Richard Henderson

target/arm: Don't put FPEXC and FPSID in org.gnu.gdb.arm.vfp XML

2021-09-30T12:42:10+00:00

Currently we send VFP XML which includes D0..D15 or D0..D31, plus FPSID, FPSCR and FPEXC. The upstream GDB tolerates this, but its definition of this XML feature does not include FPSID or FPEXC. In particular, for M-profile cores there are no FPSID or FPEXC registers, so advertising those is wrong. Move FPSID and FPEXC into their own bit of XML which we only send for A and R profile cores. This brings our definition of the XML org.gnu.gdb.arm.vfp feature into line with GDB's own (at least for non-Neon cores...) and means we don't claim to have FPSID and FPEXC on M-profile. (It seems unlikely to me that any gdbstub users really care about being able to look at FPEXC and FPSID; but we've supplied them to gdb for a decade and it's not hard to keep doing so.) Signed-off-by: Peter Maydell Reviewed-by: Richard Henderson Message-id: 20210921162901.17508-5-peter.maydell@linaro.org

target/riscv: Remove built-in GDB XML files for CSRs

2021-01-16T18:57:21+00:00

Now that we have switched to generate the RISC-V CSR XML dynamically, remove the built-in hardcoded XML files. Signed-off-by: Bin Meng Reviewed-by: Alistair Francis Message-id: 20210116054123.5457-3-bmeng.cn@gmail.com Signed-off-by: Alistair Francis