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. thanks -- PMM
