summaryrefslogtreecommitdiff
path: root/target/ppc/gdbstub.c
AgeCommit message (Collapse)Author
2019-04-26target/ppc: Style fixes for gdbstub.cDavid Gibson
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2019-02-17target/ppc: Enable reporting of SPRs to GDBFabiano Rosas
This allows reading and writing of SPRs via GDB: (gdb) p/x $srr1 $1 = 0x8000000002803033 (gdb) p/x $pvr $2 = 0x4b0201 (gdb) set $pvr=0x4b0000 (gdb) p/x $pvr $3 = 0x4b0000 The `info` command can also be used: (gdb) info registers spr For this purpose, GDB needs to be provided with an XML description of the registers (see the gdb-xml directory for examples) and a set of callbacks for reading and writing the registers must be defined. The XML file in this case is created dynamically, based on the SPRs already defined in the machine. This way we avoid the need for several XML files to suit each possible ppc machine. The gdb_{get,set}_spr_reg callbacks take an index based on the order the registers appear in the XML file. This index does not match the actual location of the registers in the env->spr array so the gdb_find_spr_idx function does that conversion. Note: GDB currently needs to know the guest endianness in order to properly print the registers values. This is done automatically by GDB when provided with the ELF file or explicitly with the `set endian <big|little>` command. Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-01-09target/ppc: move FP and VMX registers into aligned vsr register arrayMark Cave-Ayland
The VSX register array is a block of 64 128-bit registers where the first 32 registers consist of the existing 64-bit FP registers extended to 128-bit using new VSR registers, and the last 32 registers are the VMX 128-bit registers as show below: 64-bit 64-bit +--------------------+--------------------+ | FP0 | | VSR0 +--------------------+--------------------+ | FP1 | | VSR1 +--------------------+--------------------+ | ... | ... | ... +--------------------+--------------------+ | FP30 | | VSR30 +--------------------+--------------------+ | FP31 | | VSR31 +--------------------+--------------------+ | VMX0 | VSR32 +-----------------------------------------+ | VMX1 | VSR33 +-----------------------------------------+ | ... | ... +-----------------------------------------+ | VMX30 | VSR62 +-----------------------------------------+ | VMX31 | VSR63 +-----------------------------------------+ In order to allow for future conversion of VSX instructions to use TCG vector operations, recreate the same layout using an aligned version of the existing vsr register array. Since the old fpr and avr register arrays are removed, the existing callers must also be updated to use the correct offset in the vsr register array. This also includes switching the relevant VMState fields over to using subarrays to make sure that migration is preserved. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-04-27ppc: Fix size of ppc64 xer registerMichael Matz
The normal gdb definition of the XER registers is only 32 bit, and that's what the current version of power64-core.xml also says (seems copied from gdb's). But qemu's idea of the XER register is target_ulong (in CPUPPCState, ppc_gdb_register_len and ppc_cpu_gdb_read_register) That mismatch leads to the following message when attaching with gdb: Truncated register 32 in remote 'g' packet (and following on that qemu stops responding). The simple fix is to say the truth in the .xml file. But the better fix is to actually make it 32bit on the wire, as old gdbs don't support XML files for describing registers. Also the XER state in qemu doesn't seem to use the high 32 bits, so sending it off to gdb doesn't seem worthwhile. Signed-off-by: Michael Matz <matz@suse.de> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-12-20Move target-* CPU file into a target/ folderThomas Huth
We've currently got 18 architectures in QEMU, and thus 18 target-xxx folders in the root folder of the QEMU source tree. More architectures (e.g. RISC-V, AVR) are likely to be included soon, too, so the main folder of the QEMU sources slowly gets quite overcrowded with the target-xxx folders. To disburden the main folder a little bit, let's move the target-xxx folders into a dedicated target/ folder, so that target-xxx/ simply becomes target/xxx/ instead. Acked-by: Laurent Vivier <laurent@vivier.eu> [m68k part] Acked-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> [tricore part] Acked-by: Michael Walle <michael@walle.cc> [lm32 part] Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> [s390x part] Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> [s390x part] Acked-by: Eduardo Habkost <ehabkost@redhat.com> [i386 part] Acked-by: Artyom Tarasenko <atar4qemu@gmail.com> [sparc part] Acked-by: Richard Henderson <rth@twiddle.net> [alpha part] Acked-by: Max Filippov <jcmvbkbc@gmail.com> [xtensa part] Reviewed-by: David Gibson <david@gibson.dropbear.id.au> [ppc part] Acked-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> [cris&microblaze part] Acked-by: Guan Xuetao <gxt@mprc.pku.edu.cn> [unicore32 part] Signed-off-by: Thomas Huth <thuth@redhat.com>