Anonymous user
QEMU and GDB in long mode: Difference between revisions
Jump to navigation
Jump to search
add another workaround
| [unchecked revision] | [unchecked revision] |
(type) |
(add another workaround) |
||
Line 66:
Alternatively, you can patch QEMU so that you can use gdb unpatched. Be warned, this probably breaks support for debugging 32-bit code (also, compiling QEMU is hour-long task). In order to do this, replace each occurence of <code>if (TARGET_LONG_BITS == 64 && env->hflags & HF_CS64_MASK) {</code> in the file gdbstub.c with <code>if (TARGET_LONG_BITS == 64) {</code>. However, this method originates from [[topic:21836|a thread back in 2011]], and is untested since.
==Workaround 3: Connecting from GDB after long mode has been enabled==
This is an easy solution if you don't care to loose a few seconds of computation at the beginning of the emulation. The problem is that gdb is too dumb to understand that processor execution mode changed, so to workaround it you just connect after long mode has been enabled, and gdb never sees the switch. You can create this debug-with-qemu.sh script (or put this in a make target):
<source lang="text">
#!/bin/env bash
# use setsid so that ctrl+c in gdb doesn't kill qemu
setsid qemu-system-x86_64 -s -boot d -cdrom kernel.iso &
sleep 5
gdb kernel.bin -x qemudbg
</source>
where your qemudbg should have something like this:
<source lang="text">
target remote localhost:1234
</source>
and that's it (as long as you don't switch back and forth between modes).
==Other issues==
| |||