qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-ppc] [PATCH v4 2/3] target/ppc: Add GDB callbacks


From: Fabiano Rosas
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v4 2/3] target/ppc: Add GDB callbacks for SPRs
Date: Wed, 30 Jan 2019 14:30:01 -0200

Alexey Kardashevskiy <address@hidden> writes:

>
> but this is a register which does not have endianness, the endianness
> appears here because the interface between gdb and qemu is
> uint8_t*==bytestream but this interface should have fixed endianness
> imho (now it is bigendian afaict).
>
> Something is not right here...

Having a fixed endianness would not work because GDB have no way of
knowing how to represent what comes from the remote end. It will
always check the target endianness before printing a value, even if it
refers to a register:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/findvar.c;hb=HEAD#l49

So in our case the contents of mem_buf need to match both the guest
endianness *and* what GDB has set for 'show endian' because it will
detect it automatically from the ELF. If it guesses incorrectly because
there is no ELF, we need to use the 'set endian' command.

By the way, this is already the behavior for the registers that are
already implemented (e.g. $msr). Here's the commit that introduced
that:

https://git.qemu.org/?p=qemu.git;a=commitdiff;h=8a286ce4502356ce0b97a2424a2cb7

Now, what might be a source of confusion here is the fact that we
*always* do a bswap when the host is LE because QEMU thinks that the ppc
guest is always BE. That requires the maybe_bswap function to make
things right in the end.

What I could do is try to improve this by only swapping when the
guest's actual endianness (msr_le) is different from the host's. That
is not entirely within the scope of this patch, though.

Cheers




reply via email to

[Prev in Thread] Current Thread [Next in Thread]