Re: [Qemu-devel] Re: gdbstub: packet reply is too long

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]

Daniel Jacobowitz wrote:
> On Mon, Dec 29, 2008 at 03:58:47PM +0100, Jan Kiszka wrote:
>> Well, in the current gdb design, current_gdbarch is consulted when
>> disassembling the code while target_gdbarch defines the register set
>> that is exchanged with the remote stub.
> 
> This is a transitional state.  Really, there isn't supposed to be a
> 'current' gdbarch; we're already moving away from it.
> 
> Thinking about it some more you may be right about the overall
> solution though, sorry.  The target_gdbarch idea is likely to stick
> around for a while.  But some work will have to be done if current and
> target architectures have different register sets :-(

I'll start a thread on the gdb list today, CC'ing you. Would be nice if
you could then add more details on what you think would be required to
achieve this.

> 
>> I'm pretty sure that the final solution will involve extended x86
>> register sets in order to inform the frontend about the full target CPU
>> state so that it can set the right current_gdbarch automatically.
> 
> Isn't everything we need for this in eflags already?

You need CR0.PE to detect if you are in real or protected mode. And then
you need GDTR/LDTR to find the descriptor CS is pointing at, parsing it
to detect if you are running 16, 32 or 64 bit code (by default). Those
extensions would also be useful in order to decode memory addresses in
case descriptor.base != 0 (or if it's CS >> 4, ie. you are in real
mode). We have some usable patches for this @work, at least for 16 vs.
32 bit. But it's clear that more work is needed to get things upstream
and we should first agree on how things should be done there, e.g. how
to extend the register set and how to communicate that extension between
backend and frontend.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]