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'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? -- Daniel Jacobowitz CodeSourcery -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
