aboutsummaryrefslogtreecommitdiff
path: root/gdb-xml
AgeCommit message (Collapse)Author
2022-11-06gdb-xml: Fix size of EFER register on i386 architecture when debugged by GDBTaiseiIto
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 <taisei1212@outlook.jp> Message-Id: <TY0PR0101MB4285F637209075C9F65FCDA6A4479@TY0PR0101MB4285.apcprd01.prod.exchangelabs.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-09-27target/riscv: remove fixed numbering from GDB xml feature filesAndrew Burgess
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 <aburgess@redhat.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> Message-Id: <6069395f90e6fc24dac92197be815fedf42f5974.1661934573.git.aburgess@redhat.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-09-27target/riscv: remove fflags, frm, and fcsr from riscv-*-fpu.xmlAndrew Burgess
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 <aburgess@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <0fbf2a5b12e3210ff3867d5cf7022b3f3462c9c8.1661934573.git.aburgess@redhat.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-08-05target/loongarch: Update loongarch-fpu.xmlSong Gao
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 <gaosong@loongson.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220805033523.1416837-5-gaosong@loongson.cn>
2022-08-05target/loongarch: update loongarch-base64.xmlSong Gao
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 <richard.henderson@linaro.org> Signed-off-by: Song Gao <gaosong@loongson.cn> Acked-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220805033523.1416837-4-gaosong@loongson.cn>
2022-08-05target/loongarch: Fix GDB get the wrong pcSong Gao
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 <gaosong@loongson.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220805033523.1416837-2-gaosong@loongson.cn>
2022-06-06target/loongarch: Add gdb support.Xiaojuan Yang
Signed-off-by: Xiaojuan Yang <yangxiaojuan@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220606124333.2060567-42-yangxiaojuan@loongson.cn> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-02target/arm: Advertise MVE to gdb when presentPeter Maydell
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 <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211101160814.5103-1-peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-09-30target/arm: Don't put FPEXC and FPSID in org.gnu.gdb.arm.vfp XMLPeter Maydell
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 <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20210921162901.17508-5-peter.maydell@linaro.org
2021-01-16target/riscv: Remove built-in GDB XML files for CSRsBin Meng
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 <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210116054123.5457-3-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-07-10target/avr: CPU class: Add GDB supportMichael Rolnik
This includes GDB hooks for reading from wnd wrtiting to AVR registers, and xml register definition file as well. [AM: Split a larger AVR introduction patch into logical units] Suggested-by: Aleksandar Markovic <aleksandar.m.mail@gmail.com> Co-developed-by: Michael Rolnik <mrolnik@gmail.com> Co-developed-by: Sarah Harris <S.E.Harris@kent.ac.uk> Signed-off-by: Michael Rolnik <mrolnik@gmail.com> Signed-off-by: Sarah Harris <S.E.Harris@kent.ac.uk> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Aleksandar Markovic <aleksandar.m.mail@gmail.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> [thuth: Fixed avr_cpu_gdb_read_register() parameter] Signed-off-by: Thomas Huth <huth@tuxfamily.org> Message-Id: <20200705140315.260514-7-huth@tuxfamily.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2020-05-14target/arm: Use correct GDB XML for M-profile coresPeter Maydell
GDB's remote protocol requires M-profile cores to use the feature name 'org.gnu.gdb.arm.m-profile' instead of the 'org.gnu.gdb.arm.core' feature used for A- and R-profile cores. We weren't doing this, which meant GDB treated our M-profile cores like A-profile ones. This mostly doesn't matter, but for instance means that it doesn't correctly handle backtraces where an M-profile exception frame is involved. Ship a copy of GDB's arm-m-profile.xml and use it on the M-profile cores. The integer registers have the same offsets as the arm-core.xml, but register 25 is the M-profile XPSR rather than the A-profile CPSR, so we need to update arm_cpu_gdb_read_register() and arm_cpu_gdb_write_register() to handle XSPR reads and writes. Fixes: https://bugs.launchpad.net/qemu/+bug/1877136 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200507134755.13997-1-peter.maydell@linaro.org
2020-05-06target/m68k: fix gdb for m68xxxKONRAD Frederic
Currently "cf-core.xml" is sent to GDB when using any m68k flavor. Thing is it uses the "org.gnu.gdb.coldfire.core" feature name and gdb 8.3 then expects a coldfire FPU instead of the default m68881 FPU. This is not OK because the m68881 floats registers are 96 bits wide so it crashes GDB with the following error message: (gdb) target remote localhost:7960 Remote debugging using localhost:7960 warning: Register "fp0" has an unsupported size (96 bits) warning: Register "fp1" has an unsupported size (96 bits) ... Remote 'g' packet reply is too long (expected 148 bytes, got 180 bytes): \ 00000000000[...]0000 With this patch: qemu-system-m68k -M none -cpu m68020 -s -S (gdb) tar rem :1234 Remote debugging using :1234 warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0x00000000 in ?? () (gdb) p $fp0 $1 = nan(0xffffffffffffffff) Signed-off-by: KONRAD Frederic <frederic.konrad@adacore.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <1588094279-17913-3-git-send-email-frederic.konrad@adacore.com> Message-Id: <20200430190122.4592-10-alex.bennee@linaro.org>
2020-03-19target/rx: CPU definitionsYoshinori Sato
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> [PMD: Use newer QOM style, split cpu-qom.h, restrict access to extable array, use rx_cpu_tlb_fill() extracted from patch of Yoshinori Sato 'Convert to CPUClass::tlb_fill', call cpu_reset after qemu_init_vcpu, make rx_crname a function] Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200224141923.82118-7-ysato@users.sourceforge.jp> Acked-by: Richard Henderson <richard.henderson@linaro.org> [PMD: Use GByteArray in gdbstub (rebase commit a010bdbe), use device_class_set_parent_reset (rebase commit 781c67ca)] Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2019-10-28target/riscv: Expose "priv" register for GDB for readsJonathan Behrens
This patch enables a debugger to read the current privilege level via a virtual "priv" register. When compiled with CONFIG_USER_ONLY the register is still visible but always reports the value zero. Signed-off-by: Jonathan Behrens <jonathan@fintelia.io> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-03-19RISC-V: Add 64-bit gdb xml files.Jim Wilson
Signed-off-by: Jim Wilson <jimw@sifive.com> Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-03-19RISC-V: Add 32-bit gdb xml files.Jim Wilson
Signed-off-by: Jim Wilson <jimw@sifive.com> Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-02-05gdbstub: Fix i386/x86_64 machine description and add control registersDoug Gale
The machine description we send is being (silently) thrown on the floor by GDB and GDB silently uses the default machine description, because the xml parse fails on <feature> nested within <feature>. Changes to the xml in qemu source code have no effect. In addition, the default machine description has fs_base, which fails to be retrieved, which breaks the whole register window. Add it and the other control registers. Signed-off-by: Doug Gale <doug16k@gmail.com> Message-Id: <20190124040457.2546-1-doug16k@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-07-14s390x/gdb: add gs registersChristian Borntraeger
Let's provide the guarded storage registers via gdb server. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2017-06-21target-m68k: define 96bit FP registers for gdb on 680x0Laurent Vivier
Signed-off-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Richard Henderson <rth@twiddle.net> Message-Id: <20170620205121.26515-5-laurent@vivier.eu>
2017-06-07target/i386: Add GDB XML description for SSE registersAbdallah Bouassida
Add an XML description for SSE registers (XMM+MXCSR) for both X86 and X86-64 architectures in the GDB stub: - configure: Define gdb_xml_files for the X86 targets (32 and 64bit). - gdb-xml/i386-32bit-sse.xml & gdb-xml/i386-64bit-sse.xml: The XML files that contain a description of the XMM + MXCSR registers. - gdb-xml/i386-32bit.xml & gdb-xml/i386-64bit.xml: wrappers that include the XML file of the core registers and the other XML file of the SSE registers. - target/i386/cpu.c: Modify the gdb_core_xml_file to the new XML wrapper, modify the gdb_num_core_regs to fit the registers number defined in each XML file. Signed-off-by: Abdallah Bouassida <abdallah.bouassida@lauterbach.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-05-05target/i386: Add GDB XML register description supportAbdallah Bouassida
This patch implements XML target description support for X86 and X86-64 architectures in the GDB stub, as the way with ARM and PowerPC: - gdb-xml/32bit-core.xml & gdb-xml/64bit-core.xml: Adding the XML target description files, these files are picked from GDB source code. - configure: Define gdb_xml_files for X86 targets. - target/i386/cpu.c: Define gdb_core_xml_file and gdb_arch_name to add XML awareness for this architecture, modify the gdb_num_core_regs to fit the registers number defined in each XML file. Signed-off-by: Abdallah Bouassida <abdallah.bouassida@lauterbach.com> Message-Id: <2b3c8119-1602-28c7-eab4-296593877103@lauterbach.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-30target-ppc: gdbstub: Add VSX supportAnton Blanchard
Add the XML and functions to get and set VSX registers. Signed-off-by: Anton Blanchard <anton@samba.org> (fixed little-endian guests) Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-10-02s390x/gdb: expose virtualization specific registersDavid Hildenbrand
Let's expose some virtual/fake registers as virtualization specific registers. Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by: Jens Freimann <jfrei@linux.vnet.ibm.com> Message-Id: <1443689387-34473-3-git-send-email-jfrei@linux.vnet.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2015-09-07s390x/gdb: support reading/writing of control registersDavid Hildenbrand
Let's support reading and writing of control registers for kvm and tcg. We have to take care of flushing the tlb (tcg) and pushing the changed registers into kvm. Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2015-05-27gdb-xml: Include XML for s390 vector registersEric Farman
Include the vector registers XML file that is provided by gdb, and can be used by the qemu gdbserver interface. Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2014-09-01s390x/gdb: add the feature xml files for s390xDavid Hildenbrand
This patch adds the relevant s390x feature xml files taken from gdb. Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Jens Freimann <jfrei@linux.vnet.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2013-12-17target-arm: Support fp registers in gdb stubPeter Maydell
Register the aarch64-fpu XML and implement the necessary read/write handlers so we can support reading and writing of FP registers in the gdb stub. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net>
2013-09-10target-arm: Add AArch64 gdbstub supportAlexander Graf
We want to be able to debug AArch64 guests. So let's add the respective gdb stub functions and xml descriptions that allow us to do so. Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: John Rigby <john.rigby@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1378235544-22290-12-git-send-email-peter.maydell@linaro.org Message-id: 1368505980-17151-6-git-send-email-john.rigby@linaro.org [PMM: dropped unused fp regs XML for now; moved 64 bit only functions to new gdbstub64.c; these are hooked up in AArch64CPU, not via ifdefs in ARMCPU] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2009-07-12gdb-xml: fix hacks in powerpc register numberingNathan Froyd
The powerpc xml files contained a hack--an empty, non-existent register--for getting the register numbers to line up for newer (XML-aware) and older (non-XML-aware) GDB. While this hack worked in some cases, it didn't work in all cases, notably when the user used `finish' or `continue': GDB would attempt to read the non-existent register and QEMU would complain. This patch fixes things up properly. Instead of inserting a fake register, we explicitly declare the floating-point and SPE registers to start at 71. This action accomplishes the same thing as the nasty hack, except that now GDB never tries to fetch the non-existant register 70. Signed-off-by: Nathan Froyd <froydnj@codesourcery.com> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2009-03-07Work around QEMU GDB stub suboptimalityaurel32
The current XML files claim, on floating point-supporting Power chips, that $f0 is register 70. This would be fine, except that register 70 for non-XML-aware GDB is FPSCR. More importantly, 70 is less than NUM_CORE_REGS (71) for Power, so a request for register 70 goes to the "core" register reading routines, rather than the floating-point register read routine we registered with gdb_register_coprocessor. Therefore, when we are talking to an XML-aware GDB, we claim that register has zero width, which causes the rest of QEMU's GDB stub to send an error back to GDB, which causes GDB to be unable to read the floating-point registers. (The problem is also present for SPE registers and occurs in a slightly different way for Altivec registers.) The best way to fix this is to have the "core register" XML files for PPC32 and PPC64 claim that there is a 4-byte register 70, which causes $f0 to be register 71, and everything works just fine from that point forward. Signed-off-by: Nathan Froyd <froydnj@codesourcery.com> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6770 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-04The different VFP variants will never occur at the same time, and giving thempbrook
different names confuses GDB, so use org.gnu.gdb.arm.vfp for all of them. Signed-off-by: Paul Brook <paul@codesourcery.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6682 c046a42c-6fe2-441c-8c8c-71466251a162
2009-01-24target-ppc: Add XML files for PowerPC registersaurel32
These files are nearly identical to the XML files provided with GDB. The only difference is that power-{fpu,spe}.xml do not assign register numbers; the internal QEMU machinery takes care of that. Define gdb_xml_files for ppc targets in configure as well. Signed-off-by: Nathan Froyd <froydnj@codesourcery.com> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6420 c046a42c-6fe2-441c-8c8c-71466251a162
2008-10-11Add GDB XML register description support.pbrook
Signed-off-by: Paul Brook <paul@codesourcery.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5459 c046a42c-6fe2-441c-8c8c-71466251a162
generated by cgit v1.2.3 (git 2.26.2) at 2024-11-25 09:38:11 +0000