Daniel Jacobowitz wrote: > On Sun, Dec 21, 2008 at 12:44:04AM +0100, Jan Kiszka wrote: >> And that means setting current_gdbarch while keeping target_gdbarch - >> that's where reality (existing gdb code) bites us. Again, I'm not >> arguing against fixing this, I'm arguing in keeping qemu's workaround >> until this is done. I will look into the gdb part, but one after the other. > > No, it does not mean setting current_gdbarch different from > target_gdbarch. With the current gdbarch set to a 64-bit one that > accurately describes the target, GDB should be able to debug code > running in 32-bit mode. If it can't, there are simply bugs in GDB to > fix.
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. > > If you'd like to reach some solution to this problem, which I've seen > come up on the QEMU list a half-dozen times now, please describe how > you're using GDB on the [email protected] mailing list and let's see > if we can't fix the GDB bugs. I'm pretty sure that any solution is > going to involve always transferring the x86-64 register set, though. 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. That's one reason (the other is current/target_gdbarch decoupling) why I see no quick "bug fix" on the gdb side to actually solve the issue and suggest the reintroduction of the qemu workaround until gdb is enhanced appropriately. But you I right, it's time to start a discussion on the gdb list, hopefully laying the ground for a better x86 low-level support. And Maybe I actually miss some smart intermediate step towards this. Jan
signature.asc
Description: OpenPGP digital signature
