On 8/23/21 5:30 PM, Peter Maydell wrote: > On Mon, 23 Aug 2021 at 16:21, Philippe Mathieu-Daudé <phi...@redhat.com> > wrote: >> >> On 8/23/21 4:20 PM, Changbin Du wrote: >>> To resolve the issue to debug switchable targets, this serias introduces >>> basic infrastructure for gdbstub and enable support for ARM and RISC-V >>> targets. >>> >>> For example, now there is no problem to debug an big-enadian aarch64 target >>> on x86 host. >>> >>> $ qemu-system-aarch64 -gdb tcp::1234,endianness=big ... >> >> I don't understand why you need all that. >> Maybe you aren't using gdb-multiarch? >> >> You can install it or start it via QEMU Debian Docker image: >> >> $ docker run -it --rm -v /tmp:/tmp -u $UID --network=host \ >> registry.gitlab.com/qemu-project/qemu/qemu/debian10 \ >> gdb-multiarch -q \ >> --ex 'set architecture aarch64' \ >> --ex 'set endian big' >> The target architecture is assumed to be aarch64 >> The target is assumed to be big endian >> (gdb) target remote 172.17.0.1:1234 > > I don't think that will help, because an AArch64 CPU (at least > in the boards we model) will always start up in little-endian, > and our gdbstub will always transfer register data etc in > little-endian order, because gdb cannot cope with a target that > isn't always the same endianness. Fixing this requires gdb > changes to be more capable of handling dynamic target changes > (this would also help with eg debugging across 32<->64 bit switches); > as I understand it that gdb work would be pretty significant, > and at least for aarch64 pretty much nobody cares about > big-endian, so nobody's got round to doing it yet. > > Our target/ppc/gdbstub.c code takes a different tack: it > always sends register data in the same order the CPU is > currently in, which has a different set of cases when it > goes wrong.
I remember having tested the 'setend be' instruction (from https://github.com/pcrost/arm-be-test) 3 years ago using it. Connected as little endian, set breakpoint, on BP hit disconnect, set big-endian, reconnect, keep single-stepping (in the same gdb session). I doubt anything changed since.
