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: Alexey Kardashevskiy
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v4 2/3] target/ppc: Add GDB callbacks for SPRs
Date: Thu, 31 Jan 2019 18:57:13 +1100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0


On 31/01/2019 03:30, Fabiano Rosas wrote:
> 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 definitely would. A register is stored as "unsigned long" in QEMU and
all gdb has to do is printf("%lx") and that is it. The problem is that
we want to pass it as a byte stream from the gdb_read_register() hook
all the way to gdb and for some reason gdb does not define endianness of
that stream but rather tries guessing the endianness which is broken.

Today I was debugging rtas/clientinterface calls which a little endian
kernel makes and these calls need to switch to the big endian first. And
gdb goes nuts when this switch happens (note that I did not give an ELF
to gdb this time so it picked LE itself). Even if it could fetch the
endianness from QEMU, it would fail as it is an LE bit in MSR which is a
register which is parsed according to the gdb's idea of endianness :)


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

The bytestream for registers should have fixed endianness. But looking
at the gdb code makes me think it is not going to happen :(


> That
> is not entirely within the scope of this patch, though.

True. But since you are touching this, may be you could fix gdb too :)

Does gdb tell QEMU about what endianness it thinks that QEMU is using?
Or can it read it from QEMU? I cannot easily spot this in QEMU...


-- 
Alexey



reply via email to

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