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
signature.asc
Description: OpenPGP digital signature
