* [Qemu-devel] [Bug 1686170] [NEW] qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options
@ 2017-04-25 18:31 Alain Kalker
2017-04-26 15:24 ` [Qemu-devel] [Bug 1686170] " Alain Kalker
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: Alain Kalker @ 2017-04-25 18:31 UTC (permalink / raw)
To: qemu-devel
Public bug reported:
OS: Void Linux x86_64 (glibc)
QEMU version: 2.9.0
GDB version: 7.12.1
Problem description:
After I updated QEMU from version 2.8.1 to 2.9.0, I found that when I try to connect GDB to a running QEMU and try to debug Real mode machine code, I can no longer set architecture to 'i8086'.
To be able to connect to QEMU from GDB at all, I have to specify one of the 64 bit architectures, which among other things leads to incorrect disassembly listings. This makes debugging Real mode bootloaders, bootsectors and BIOS code much more difficult.
Steps to reproduce:
- Run QEMU
- In another terminal, run GDB
- In GDB, connect to QEMU
- In GDB, disassemble some Real mode machine code.
Expected results (from QEMU version 2.8.1):
[terminal #1]
$ qemu-system-x86_64 -S -s
[terminal #2]
(gdb) set architecture i8086
warning: A handler for the OS ABI "GNU/Linux" is not built
into this configuration
of GDB. Attempting to continue with the default i8086 settings.
The target architecture is assumed to be i8086
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x0000fff0 in ?? ()
(gdb) x/i $cs*16+$eip
0xffff0: ljmp $0xf000,$0xe05b
Actual results:
[terminal #1]
$ qemu-system-x86_64 -S -s
[terminal #2]
$ gdb -q
(gdb) set architecture i8086
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default i8086 settings.
The target architecture is assumed to be i8086
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
Remote 'g' packet reply is too long:
[..snip..]
Workarounds tried:
- Try different architecures
(gdb) set architecture i386:intel
The target architecture is assumed to be i386:intel
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
Remote 'g' packet reply is too long:
[..snip..]
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x000000000000fff0 in ?? ()
The last try finally allowed me to connect to QEMU, but as can be
expected from using an incorrect architecture setting, disassembly
output is complete gibberish:
(gdb) x/10i $cs*16+$rip
0xffff0: (bad)
0xffff1: pop %rbx
0xffff2: loopne 0xffff4
0xffff4: lock xor %dh,(%rsi)
0xffff7: (bad)
0xffff8: xor (%rbx),%dh
0xffffa: (bad)
0xffffb: cmp %edi,(%rcx)
0xffffd: add %bh,%ah
0xfffff: add %al,(%rax)
Discussion:
I think I've traced the problem to the following commit: "x86: Fix x86_64 'g' packet response to gdb from 32-bit mode."[1].
While I admire the effort to make life for people using GDB to debug QEMU VMs, I think the problem here is with GDB and can't be fixed entirely from the side of QEMU without breaking other features.
In fact, there is a well-known workaround to this problem published on
OSDev Wiki (Workaround #1)[2] which doesn't require patching either QEMU
or GDB. This workaround has worked for me using several previous
versions of QEMU.
$ gdb -q
(gdb) set architecture i8086
(gdb) target remote :1234
(gdb) break some_breakpoint_in_32_bit_or_64_bit_code
(gdb) continue
[...]
Remote 'g' packet reply is too long: [...]
(gdb) disconnect # IMPORTANT STEP #1
(gdb) set architecture i386:x86-64
(gdb) target remote :1234 # IMPORTANT STEP #2
(gdb) continue
[1]: http://git.qemu.org/?p=qemu.git;a=commit;h=e3592bc9d841c397eeda87f0019fab94ff71004b
[2]: http://wiki.osdev.org/QEMU_and_GDB_in_long_mode#Workaround_1:_Reconnecting
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1686170
Title:
qemu-system-x86_64+gdb: unable to correctly disassemble "real mode"
(i8086) instructions after attaching to QEMU started with "-S -s"
options
Status in QEMU:
New
Bug description:
OS: Void Linux x86_64 (glibc)
QEMU version: 2.9.0
GDB version: 7.12.1
Problem description:
After I updated QEMU from version 2.8.1 to 2.9.0, I found that when I try to connect GDB to a running QEMU and try to debug Real mode machine code, I can no longer set architecture to 'i8086'.
To be able to connect to QEMU from GDB at all, I have to specify one of the 64 bit architectures, which among other things leads to incorrect disassembly listings. This makes debugging Real mode bootloaders, bootsectors and BIOS code much more difficult.
Steps to reproduce:
- Run QEMU
- In another terminal, run GDB
- In GDB, connect to QEMU
- In GDB, disassemble some Real mode machine code.
Expected results (from QEMU version 2.8.1):
[terminal #1]
$ qemu-system-x86_64 -S -s
[terminal #2]
(gdb) set architecture i8086
warning: A handler for the OS ABI "GNU/Linux" is not built
into this configuration
of GDB. Attempting to continue with the default i8086 settings.
The target architecture is assumed to be i8086
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x0000fff0 in ?? ()
(gdb) x/i $cs*16+$eip
0xffff0: ljmp $0xf000,$0xe05b
Actual results:
[terminal #1]
$ qemu-system-x86_64 -S -s
[terminal #2]
$ gdb -q
(gdb) set architecture i8086
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default i8086 settings.
The target architecture is assumed to be i8086
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
Remote 'g' packet reply is too long:
[..snip..]
Workarounds tried:
- Try different architecures
(gdb) set architecture i386:intel
The target architecture is assumed to be i386:intel
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
Remote 'g' packet reply is too long:
[..snip..]
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x000000000000fff0 in ?? ()
The last try finally allowed me to connect to QEMU, but as can be
expected from using an incorrect architecture setting, disassembly
output is complete gibberish:
(gdb) x/10i $cs*16+$rip
0xffff0: (bad)
0xffff1: pop %rbx
0xffff2: loopne 0xffff4
0xffff4: lock xor %dh,(%rsi)
0xffff7: (bad)
0xffff8: xor (%rbx),%dh
0xffffa: (bad)
0xffffb: cmp %edi,(%rcx)
0xffffd: add %bh,%ah
0xfffff: add %al,(%rax)
Discussion:
I think I've traced the problem to the following commit: "x86: Fix x86_64 'g' packet response to gdb from 32-bit mode."[1].
While I admire the effort to make life for people using GDB to debug QEMU VMs, I think the problem here is with GDB and can't be fixed entirely from the side of QEMU without breaking other features.
In fact, there is a well-known workaround to this problem published on
OSDev Wiki (Workaround #1)[2] which doesn't require patching either
QEMU or GDB. This workaround has worked for me using several previous
versions of QEMU.
$ gdb -q
(gdb) set architecture i8086
(gdb) target remote :1234
(gdb) break some_breakpoint_in_32_bit_or_64_bit_code
(gdb) continue
[...]
Remote 'g' packet reply is too long: [...]
(gdb) disconnect # IMPORTANT STEP #1
(gdb) set architecture i386:x86-64
(gdb) target remote :1234 # IMPORTANT STEP #2
(gdb) continue
[1]: http://git.qemu.org/?p=qemu.git;a=commit;h=e3592bc9d841c397eeda87f0019fab94ff71004b
[2]: http://wiki.osdev.org/QEMU_and_GDB_in_long_mode#Workaround_1:_Reconnecting
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1686170/+subscriptions
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Qemu-devel] [Bug 1686170] Re: qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options
2017-04-25 18:31 [Qemu-devel] [Bug 1686170] [NEW] qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options Alain Kalker
@ 2017-04-26 15:24 ` Alain Kalker
2017-07-10 16:55 ` Duane Voth
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Alain Kalker @ 2017-04-26 15:24 UTC (permalink / raw)
To: qemu-devel
If it is decided to retain the change, please do consider adding a
commandline option to enable debugging Real mode code after `set
architecture i8086`, even if this requires the GDB workaround previously
mentioned. Thanks in advance.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1686170
Title:
qemu-system-x86_64+gdb: unable to correctly disassemble "real mode"
(i8086) instructions after attaching to QEMU started with "-S -s"
options
Status in QEMU:
New
Bug description:
OS: Void Linux x86_64 (glibc)
QEMU version: 2.9.0
GDB version: 7.12.1
Problem description:
After I updated QEMU from version 2.8.1 to 2.9.0, I found that when I try to connect GDB to a running QEMU and try to debug Real mode machine code, I can no longer set architecture to 'i8086'.
To be able to connect to QEMU from GDB at all, I have to specify one of the 64 bit architectures, which among other things leads to incorrect disassembly listings. This makes debugging Real mode bootloaders, bootsectors and BIOS code much more difficult.
Steps to reproduce:
- Run QEMU
- In another terminal, run GDB
- In GDB, connect to QEMU
- In GDB, disassemble some Real mode machine code.
Expected results (from QEMU version 2.8.1):
[terminal #1]
$ qemu-system-x86_64 -S -s
[terminal #2]
(gdb) set architecture i8086
warning: A handler for the OS ABI "GNU/Linux" is not built
into this configuration
of GDB. Attempting to continue with the default i8086 settings.
The target architecture is assumed to be i8086
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x0000fff0 in ?? ()
(gdb) x/i $cs*16+$eip
0xffff0: ljmp $0xf000,$0xe05b
Actual results:
[terminal #1]
$ qemu-system-x86_64 -S -s
[terminal #2]
$ gdb -q
(gdb) set architecture i8086
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default i8086 settings.
The target architecture is assumed to be i8086
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
Remote 'g' packet reply is too long:
[..snip..]
Workarounds tried:
- Try different architecures
(gdb) set architecture i386:intel
The target architecture is assumed to be i386:intel
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
Remote 'g' packet reply is too long:
[..snip..]
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x000000000000fff0 in ?? ()
The last try finally allowed me to connect to QEMU, but as can be
expected from using an incorrect architecture setting, disassembly
output is complete gibberish:
(gdb) x/10i $cs*16+$rip
0xffff0: (bad)
0xffff1: pop %rbx
0xffff2: loopne 0xffff4
0xffff4: lock xor %dh,(%rsi)
0xffff7: (bad)
0xffff8: xor (%rbx),%dh
0xffffa: (bad)
0xffffb: cmp %edi,(%rcx)
0xffffd: add %bh,%ah
0xfffff: add %al,(%rax)
Discussion:
I think I've traced the problem to the following commit: "x86: Fix x86_64 'g' packet response to gdb from 32-bit mode."[1].
While I admire the effort to make life for people using GDB to debug QEMU VMs, I think the problem here is with GDB and can't be fixed entirely from the side of QEMU without breaking other features.
In fact, there is a well-known workaround to this problem published on
OSDev Wiki (Workaround #1)[2] which doesn't require patching either
QEMU or GDB. This workaround has worked for me using several previous
versions of QEMU.
$ gdb -q
(gdb) set architecture i8086
(gdb) target remote :1234
(gdb) break some_breakpoint_in_32_bit_or_64_bit_code
(gdb) continue
[...]
Remote 'g' packet reply is too long: [...]
(gdb) disconnect # IMPORTANT STEP #1
(gdb) set architecture i386:x86-64
(gdb) target remote :1234 # IMPORTANT STEP #2
(gdb) continue
[1]: http://git.qemu.org/?p=qemu.git;a=commit;h=e3592bc9d841c397eeda87f0019fab94ff71004b
[2]: http://wiki.osdev.org/QEMU_and_GDB_in_long_mode#Workaround_1:_Reconnecting
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1686170/+subscriptions
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Qemu-devel] [Bug 1686170] Re: qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options
2017-04-25 18:31 [Qemu-devel] [Bug 1686170] [NEW] qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options Alain Kalker
2017-04-26 15:24 ` [Qemu-devel] [Bug 1686170] " Alain Kalker
@ 2017-07-10 16:55 ` Duane Voth
2018-05-12 12:10 ` Vladislav K. Valtchev
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Duane Voth @ 2017-07-10 16:55 UTC (permalink / raw)
To: qemu-devel
Apparently none of the 32bit x86 modes are supported in 2.9 version of
qemu-system-x86_64. I realize the desire to simplify the code, and
separate i386 from x86_64, but x86_64 really does need to support all
the modes in which the processor can operate. True that for major
operating systems the processor is only briefly in any 32bit mode, but
for boot ROM and boot loader work, and non-mainstream kernels we still
very much need 32bit support *in* the x86_64 qemu.
Previously the 'g' RDP query (gdbstub.c:1056) would send a different
length of reg data depending on in which mode the cpu was currently
operating. Although maybe not a great ABI, it was sufficient to tell
exactly when the cpu changed states and front end debuggers need to know
this.
Unfortunately the much more portable new .xml register definition scheme needs to be changed to properly support multiple register sets (with different names sizes etc.), but x86 is not the only processor to have multiple personalities.
An example implementation for x86 could be that the "top" level xml file i386-64bit.xml describes all the different possible modes (something like):
<feature name="org.gnu.gdb.i386.64bit">
<xi:include href="i386-64bit-core.xml"/>
<xi:include href="i386-64bit-sse.xml"/>
</feature>
<feature name="org.gnu.gdb.i386.32bit.protectedmode">
<xi:include href="i386-32bit-core.xml"/>
<xi:include href="i386-32bit-sse.xml"/>
</feature>
<feature name="org.gnu.gdb.i386.32bit.realmode">
<xi:include href="i386-i8086-core.xml"/>
</feature>
all of which are loaded when the frontend starts. The 'g' RDP response
should then start with one of the feature names (or an abbreviated
unique id).
In fact, ring0 vs ring1-3 should likely also have different xml files as
the crX config registers need to be sent when in ring 0 as well.
Commit that made this change:
https://github.com/qemu/qemu/commit/00fcd100c3f47445f6a59d39e11601460880cfe4
#diff-b8f1948d6e81e8ccdbe828ba7973c483
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1686170
Title:
qemu-system-x86_64+gdb: unable to correctly disassemble "real mode"
(i8086) instructions after attaching to QEMU started with "-S -s"
options
Status in QEMU:
New
Bug description:
OS: Void Linux x86_64 (glibc)
QEMU version: 2.9.0
GDB version: 7.12.1
Problem description:
After I updated QEMU from version 2.8.1 to 2.9.0, I found that when I try to connect GDB to a running QEMU and try to debug Real mode machine code, I can no longer set architecture to 'i8086'.
To be able to connect to QEMU from GDB at all, I have to specify one of the 64 bit architectures, which among other things leads to incorrect disassembly listings. This makes debugging Real mode bootloaders, bootsectors and BIOS code much more difficult.
Steps to reproduce:
- Run QEMU
- In another terminal, run GDB
- In GDB, connect to QEMU
- In GDB, disassemble some Real mode machine code.
Expected results (from QEMU version 2.8.1):
[terminal #1]
$ qemu-system-x86_64 -S -s
[terminal #2]
(gdb) set architecture i8086
warning: A handler for the OS ABI "GNU/Linux" is not built
into this configuration
of GDB. Attempting to continue with the default i8086 settings.
The target architecture is assumed to be i8086
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x0000fff0 in ?? ()
(gdb) x/i $cs*16+$eip
0xffff0: ljmp $0xf000,$0xe05b
Actual results:
[terminal #1]
$ qemu-system-x86_64 -S -s
[terminal #2]
$ gdb -q
(gdb) set architecture i8086
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default i8086 settings.
The target architecture is assumed to be i8086
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
Remote 'g' packet reply is too long:
[..snip..]
Workarounds tried:
- Try different architecures
(gdb) set architecture i386:intel
The target architecture is assumed to be i386:intel
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
Remote 'g' packet reply is too long:
[..snip..]
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x000000000000fff0 in ?? ()
The last try finally allowed me to connect to QEMU, but as can be
expected from using an incorrect architecture setting, disassembly
output is complete gibberish:
(gdb) x/10i $cs*16+$rip
0xffff0: (bad)
0xffff1: pop %rbx
0xffff2: loopne 0xffff4
0xffff4: lock xor %dh,(%rsi)
0xffff7: (bad)
0xffff8: xor (%rbx),%dh
0xffffa: (bad)
0xffffb: cmp %edi,(%rcx)
0xffffd: add %bh,%ah
0xfffff: add %al,(%rax)
Discussion:
I think I've traced the problem to the following commit: "x86: Fix x86_64 'g' packet response to gdb from 32-bit mode."[1].
While I admire the effort to make life for people using GDB to debug QEMU VMs, I think the problem here is with GDB and can't be fixed entirely from the side of QEMU without breaking other features.
In fact, there is a well-known workaround to this problem published on
OSDev Wiki (Workaround #1)[2] which doesn't require patching either
QEMU or GDB. This workaround has worked for me using several previous
versions of QEMU.
$ gdb -q
(gdb) set architecture i8086
(gdb) target remote :1234
(gdb) break some_breakpoint_in_32_bit_or_64_bit_code
(gdb) continue
[...]
Remote 'g' packet reply is too long: [...]
(gdb) disconnect # IMPORTANT STEP #1
(gdb) set architecture i386:x86-64
(gdb) target remote :1234 # IMPORTANT STEP #2
(gdb) continue
[1]: http://git.qemu.org/?p=qemu.git;a=commit;h=e3592bc9d841c397eeda87f0019fab94ff71004b
[2]: http://wiki.osdev.org/QEMU_and_GDB_in_long_mode#Workaround_1:_Reconnecting
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1686170/+subscriptions
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Qemu-devel] [Bug 1686170] Re: qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options
2017-04-25 18:31 [Qemu-devel] [Bug 1686170] [NEW] qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options Alain Kalker
2017-04-26 15:24 ` [Qemu-devel] [Bug 1686170] " Alain Kalker
2017-07-10 16:55 ` Duane Voth
@ 2018-05-12 12:10 ` Vladislav K. Valtchev
2019-12-27 3:08 ` Marek Dolata
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Vladislav K. Valtchev @ 2018-05-12 12:10 UTC (permalink / raw)
To: qemu-devel
Hi,
are there any updates on this issue?
I'm using qemu 2.11.1 and I believe I'm experiencing the same problem explained by Duane.
I'm unable to debug with gdb 32-bit kernel code using qemu-system-x86_64. GDB complains that the target architecture is x86_64, even if VM's CPU is currently running in 32-bit protected mode.
Steps to reproduce:
- qemu-system-x86_64 -s -hda <a bootable image using PM32> [note: no need to use -S]
- gdb
- (in gdb): set arch i386
- (in gdb): target remote localhost:1234 [note: no need to specify an ELF binary]
I get:
Remote debugging using localhost:1234
warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
Remote 'g' packet reply is too long (expected 312 bytes, got 536 bytes): [SKIPPING the raw data]
Unfortunately, I was unable to find any workaround.
Not even patching GDB as suggested here https://wiki.osdev.org/QEMU_and_GDB_in_long_mode
really works (because forcing GDB to ignore the exceeding data, does not really solve the whole problem).
I remember that with older versions of qemu the behavior was different
and by just using gdb's "set arch" command I was able to debug both
32-bit and 64-bit code running on a x86_64 qemu VM.
Could the older behavior be restored somehow? Even by adding an ad-hoc
command-line option would be OK.
Thanks a lot,
Vlad
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1686170
Title:
qemu-system-x86_64+gdb: unable to correctly disassemble "real mode"
(i8086) instructions after attaching to QEMU started with "-S -s"
options
Status in QEMU:
New
Bug description:
OS: Void Linux x86_64 (glibc)
QEMU version: 2.9.0
GDB version: 7.12.1
Problem description:
After I updated QEMU from version 2.8.1 to 2.9.0, I found that when I try to connect GDB to a running QEMU and try to debug Real mode machine code, I can no longer set architecture to 'i8086'.
To be able to connect to QEMU from GDB at all, I have to specify one of the 64 bit architectures, which among other things leads to incorrect disassembly listings. This makes debugging Real mode bootloaders, bootsectors and BIOS code much more difficult.
Steps to reproduce:
- Run QEMU
- In another terminal, run GDB
- In GDB, connect to QEMU
- In GDB, disassemble some Real mode machine code.
Expected results (from QEMU version 2.8.1):
[terminal #1]
$ qemu-system-x86_64 -S -s
[terminal #2]
(gdb) set architecture i8086
warning: A handler for the OS ABI "GNU/Linux" is not built
into this configuration
of GDB. Attempting to continue with the default i8086 settings.
The target architecture is assumed to be i8086
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x0000fff0 in ?? ()
(gdb) x/i $cs*16+$eip
0xffff0: ljmp $0xf000,$0xe05b
Actual results:
[terminal #1]
$ qemu-system-x86_64 -S -s
[terminal #2]
$ gdb -q
(gdb) set architecture i8086
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default i8086 settings.
The target architecture is assumed to be i8086
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
Remote 'g' packet reply is too long:
[..snip..]
Workarounds tried:
- Try different architecures
(gdb) set architecture i386:intel
The target architecture is assumed to be i386:intel
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
Remote 'g' packet reply is too long:
[..snip..]
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x000000000000fff0 in ?? ()
The last try finally allowed me to connect to QEMU, but as can be
expected from using an incorrect architecture setting, disassembly
output is complete gibberish:
(gdb) x/10i $cs*16+$rip
0xffff0: (bad)
0xffff1: pop %rbx
0xffff2: loopne 0xffff4
0xffff4: lock xor %dh,(%rsi)
0xffff7: (bad)
0xffff8: xor (%rbx),%dh
0xffffa: (bad)
0xffffb: cmp %edi,(%rcx)
0xffffd: add %bh,%ah
0xfffff: add %al,(%rax)
Discussion:
I think I've traced the problem to the following commit: "x86: Fix x86_64 'g' packet response to gdb from 32-bit mode."[1].
While I admire the effort to make life for people using GDB to debug QEMU VMs, I think the problem here is with GDB and can't be fixed entirely from the side of QEMU without breaking other features.
In fact, there is a well-known workaround to this problem published on
OSDev Wiki (Workaround #1)[2] which doesn't require patching either
QEMU or GDB. This workaround has worked for me using several previous
versions of QEMU.
$ gdb -q
(gdb) set architecture i8086
(gdb) target remote :1234
(gdb) break some_breakpoint_in_32_bit_or_64_bit_code
(gdb) continue
[...]
Remote 'g' packet reply is too long: [...]
(gdb) disconnect # IMPORTANT STEP #1
(gdb) set architecture i386:x86-64
(gdb) target remote :1234 # IMPORTANT STEP #2
(gdb) continue
[1]: http://git.qemu.org/?p=qemu.git;a=commit;h=e3592bc9d841c397eeda87f0019fab94ff71004b
[2]: http://wiki.osdev.org/QEMU_and_GDB_in_long_mode#Workaround_1:_Reconnecting
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1686170/+subscriptions
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug 1686170] Re: qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options
2017-04-25 18:31 [Qemu-devel] [Bug 1686170] [NEW] qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options Alain Kalker
` (2 preceding siblings ...)
2018-05-12 12:10 ` Vladislav K. Valtchev
@ 2019-12-27 3:08 ` Marek Dolata
2020-04-26 7:17 ` chenhao
2021-05-05 6:57 ` Thomas Huth
5 siblings, 0 replies; 7+ messages in thread
From: Marek Dolata @ 2019-12-27 3:08 UTC (permalink / raw)
To: qemu-devel
I had the same issue. My workaround is to force the target description
to be loaded from a local xml file where the architecture tag is i8086.
I took the one that was sent over the network from the server to the
client and changed the architecture tag from i386 to i8086 and also the
size of the i386_efer flags from 8 to 4.
$ gdb -q
(gdb) set tdesc filename ./target.xml
(gdb) target remote :29096
...
(gdb) x/i 0x10*$cs+$pc
0xffff0: ljmp $0xf000,$0xe05b
(gdb) quit
$ cat target.xml
<?xml version="1.0"?>
<!-- Copyright (C) 2010-2017 Free Software Foundation, Inc.
Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved. -->
<!-- I386 with SSE -->
<!DOCTYPE target SYSTEM "gdb-target.dtd">
<target>
<architecture>i8086</architecture>
<feature name="org.gnu.gdb.i386.core">
<flags id="i386_eflags" size="4">
<field name="" start="22" end="31"/>
<field name="ID" start="21" end="21"/>
<field name="VIP" start="20" end="20"/>
<field name="VIF" start="19" end="19"/>
<field name="AC" start="18" end="18"/>
<field name="VM" start="17" end="17"/>
<field name="RF" start="16" end="16"/>
<field name="" start="15" end="15"/>
<field name="NT" start="14" end="14"/>
<field name="IOPL" start="12" end="13"/>
<field name="OF" start="11" end="11"/>
<field name="DF" start="10" end="10"/>
<field name="IF" start="9" end="9"/>
<field name="TF" start="8" end="8"/>
<field name="SF" start="7" end="7"/>
<field name="ZF" start="6" end="6"/>
<field name="" start="5" end="5"/>
<field name="AF" start="4" end="4"/>
<field name="" start="3" end="3"/>
<field name="PF" start="2" end="2"/>
<field name="" start="1" end="1"/>
<field name="CF" start="0" end="0"/>
</flags>
<reg name="eax" bitsize="32" type="int32" regnum="0"/>
<reg name="ecx" bitsize="32" type="int32"/>
<reg name="edx" bitsize="32" type="int32"/>
<reg name="ebx" bitsize="32" type="int32"/>
<reg name="esp" bitsize="32" type="data_ptr"/>
<reg name="ebp" bitsize="32" type="data_ptr"/>
<reg name="esi" bitsize="32" type="int32"/>
<reg name="edi" bitsize="32" type="int32"/>
<reg name="eip" bitsize="32" type="code_ptr"/>
<reg name="eflags" bitsize="32" type="i386_eflags"/>
<reg name="cs" bitsize="32" type="int32"/>
<reg name="ss" bitsize="32" type="int32"/>
<reg name="ds" bitsize="32" type="int32"/>
<reg name="es" bitsize="32" type="int32"/>
<reg name="fs" bitsize="32" type="int32"/>
<reg name="gs" bitsize="32" type="int32"/>
<!--reg name="cs_base" bitsize="32" type="int32"/>
<reg name="ss_base" bitsize="32" type="int32"/>
<reg name="ds_base" bitsize="32" type="int32"/>
<reg name="es_base" bitsize="32" type="int32"/-->
<reg name="fs_base" bitsize="32" type="int32"/>
<reg name="gs_base" bitsize="32" type="int32"/>
<reg name="k_gs_base" bitsize="32" type="int32"/>
<flags id="i386_cr0" size="4">
<field name="PG" start="31" end="31"/>
<field name="CD" start="30" end="30"/>
<field name="NW" start="29" end="29"/>
<field name="AM" start="18" end="18"/>
<field name="WP" start="16" end="16"/>
<field name="NE" start="5" end="5"/>
<field name="ET" start="4" end="4"/>
<field name="TS" start="3" end="3"/>
<field name="EM" start="2" end="2"/>
<field name="MP" start="1" end="1"/>
<field name="PE" start="0" end="0"/>
</flags>
<flags id="i386_cr3" size="4">
<field name="PDBR" start="12" end="31"/>
<!--field name="" start="3" end="11"/>
<field name="WT" start="2" end="2"/>
<field name="CD" start="1" end="1"/>
<field name="" start="0" end="0"/-->
<field name="PCID" start="0" end="11"/>
</flags>
<flags id="i386_cr4" size="4">
<field name="VME" start="0" end="0"/>
<field name="PVI" start="1" end="1"/>
<field name="TSD" start="2" end="2"/>
<field name="DE" start="3" end="3"/>
<field name="PSE" start="4" end="4"/>
<field name="PAE" start="5" end="5"/>
<field name="MCE" start="6" end="6"/>
<field name="PGE" start="7" end="7"/>
<field name="PCE" start="8" end="8"/>
<field name="OSFXSR" start="9" end="9"/>
<field name="OSXMMEXCPT" start="10" end="10"/>
<field name="UMIP" start="11" end="11"/>
<field name="LA57" start="12" end="12"/>
<field name="VMXE" start="13" end="13"/>
<field name="SMXE" start="14" end="14"/>
<field name="FSGSBASE" start="16" end="16"/>
<field name="PCIDE" start="17" end="17"/>
<field name="OSXSAVE" start="18" end="18"/>
<field name="SMEP" start="20" end="20"/>
<field name="SMAP" start="21" end="21"/>
<field name="PKE" start="22" end="22"/>
</flags>
<flags id="i386_efer" size="4">
<field name="TCE" start="15" end="15"/>
<field name="FFXSR" start="14" end="14"/>
<field name="LMSLE" start="13" end="13"/>
<field name="SVME" start="12" end="12"/>
<field name="NXE" start="11" end="11"/>
<field name="LMA" start="10" end="10"/>
<field name="LME" start="8" end="8"/>
<field name="SCE" start="0" end="0"/>
</flags>
<reg name="cr0" bitsize="32" type="i386_cr0"/>
<reg name="cr2" bitsize="32" type="int32"/>
<reg name="cr3" bitsize="32" type="i386_cr3"/>
<reg name="cr4" bitsize="32" type="i386_cr4"/>
<reg name="cr8" bitsize="32" type="int32"/>
<reg name="efer" bitsize="32" type="i386_efer"/>
<reg name="st0" bitsize="80" type="i387_ext"/>
<reg name="st1" bitsize="80" type="i387_ext"/>
<reg name="st2" bitsize="80" type="i387_ext"/>
<reg name="st3" bitsize="80" type="i387_ext"/>
<reg name="st4" bitsize="80" type="i387_ext"/>
<reg name="st5" bitsize="80" type="i387_ext"/>
<reg name="st6" bitsize="80" type="i387_ext"/>
<reg name="st7" bitsize="80" type="i387_ext"/>
<reg name="fctrl" bitsize="32" type="int" group="float"/>
<reg name="fstat" bitsize="32" type="int" group="float"/>
<reg name="ftag" bitsize="32" type="int" group="float"/>
<reg name="fiseg" bitsize="32" type="int" group="float"/>
<reg name="fioff" bitsize="32" type="int" group="float"/>
<reg name="foseg" bitsize="32" type="int" group="float"/>
<reg name="fooff" bitsize="32" type="int" group="float"/>
<reg name="fop" bitsize="32" type="int" group="float"/>
<!--/feature>
<feature name="org.gnu.gdb.i386.32bit.sse"-->
<vector id="v4f" type="ieee_single" count="4"/>
<vector id="v2d" type="ieee_double" count="2"/>
<vector id="v16i8" type="int8" count="16"/>
<vector id="v8i16" type="int16" count="8"/>
<vector id="v4i32" type="int32" count="4"/>
<vector id="v2i64" type="int64" count="2"/>
<union id="vec128">
<field name="v4_float" type="v4f"/>
<field name="v2_double" type="v2d"/>
<field name="v16_int8" type="v16i8"/>
<field name="v8_int16" type="v8i16"/>
<field name="v4_int32" type="v4i32"/>
<field name="v2_int64" type="v2i64"/>
<field name="uint128" type="uint128"/>
</union>
<flags id="i386_mxcsr" size="4">
<field name="IE" start="0" end="0"/>
<field name="DE" start="1" end="1"/>
<field name="ZE" start="2" end="2"/>
<field name="OE" start="3" end="3"/>
<field name="UE" start="4" end="4"/>
<field name="PE" start="5" end="5"/>
<field name="DAZ" start="6" end="6"/>
<field name="IM" start="7" end="7"/>
<field name="DM" start="8" end="8"/>
<field name="ZM" start="9" end="9"/>
<field name="OM" start="10" end="10"/>
<field name="UM" start="11" end="11"/>
<field name="PM" start="12" end="12"/>
<field name="FZ" start="15" end="15"/>
</flags>
<reg name="xmm0" bitsize="128" type="vec128"/>
<reg name="xmm1" bitsize="128" type="vec128"/>
<reg name="xmm2" bitsize="128" type="vec128"/>
<reg name="xmm3" bitsize="128" type="vec128"/>
<reg name="xmm4" bitsize="128" type="vec128"/>
<reg name="xmm5" bitsize="128" type="vec128"/>
<reg name="xmm6" bitsize="128" type="vec128"/>
<reg name="xmm7" bitsize="128" type="vec128"/>
<reg name="mxcsr" bitsize="32" type="i386_mxcsr" group="vector"/>
</feature>
</target>
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1686170
Title:
qemu-system-x86_64+gdb: unable to correctly disassemble "real mode"
(i8086) instructions after attaching to QEMU started with "-S -s"
options
Status in QEMU:
New
Bug description:
OS: Void Linux x86_64 (glibc)
QEMU version: 2.9.0
GDB version: 7.12.1
Problem description:
After I updated QEMU from version 2.8.1 to 2.9.0, I found that when I try to connect GDB to a running QEMU and try to debug Real mode machine code, I can no longer set architecture to 'i8086'.
To be able to connect to QEMU from GDB at all, I have to specify one of the 64 bit architectures, which among other things leads to incorrect disassembly listings. This makes debugging Real mode bootloaders, bootsectors and BIOS code much more difficult.
Steps to reproduce:
- Run QEMU
- In another terminal, run GDB
- In GDB, connect to QEMU
- In GDB, disassemble some Real mode machine code.
Expected results (from QEMU version 2.8.1):
[terminal #1]
$ qemu-system-x86_64 -S -s
[terminal #2]
(gdb) set architecture i8086
warning: A handler for the OS ABI "GNU/Linux" is not built
into this configuration
of GDB. Attempting to continue with the default i8086 settings.
The target architecture is assumed to be i8086
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x0000fff0 in ?? ()
(gdb) x/i $cs*16+$eip
0xffff0: ljmp $0xf000,$0xe05b
Actual results:
[terminal #1]
$ qemu-system-x86_64 -S -s
[terminal #2]
$ gdb -q
(gdb) set architecture i8086
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default i8086 settings.
The target architecture is assumed to be i8086
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
Remote 'g' packet reply is too long:
[..snip..]
Workarounds tried:
- Try different architecures
(gdb) set architecture i386:intel
The target architecture is assumed to be i386:intel
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
Remote 'g' packet reply is too long:
[..snip..]
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x000000000000fff0 in ?? ()
The last try finally allowed me to connect to QEMU, but as can be
expected from using an incorrect architecture setting, disassembly
output is complete gibberish:
(gdb) x/10i $cs*16+$rip
0xffff0: (bad)
0xffff1: pop %rbx
0xffff2: loopne 0xffff4
0xffff4: lock xor %dh,(%rsi)
0xffff7: (bad)
0xffff8: xor (%rbx),%dh
0xffffa: (bad)
0xffffb: cmp %edi,(%rcx)
0xffffd: add %bh,%ah
0xfffff: add %al,(%rax)
Discussion:
I think I've traced the problem to the following commit: "x86: Fix x86_64 'g' packet response to gdb from 32-bit mode."[1].
While I admire the effort to make life for people using GDB to debug QEMU VMs, I think the problem here is with GDB and can't be fixed entirely from the side of QEMU without breaking other features.
In fact, there is a well-known workaround to this problem published on
OSDev Wiki (Workaround #1)[2] which doesn't require patching either
QEMU or GDB. This workaround has worked for me using several previous
versions of QEMU.
$ gdb -q
(gdb) set architecture i8086
(gdb) target remote :1234
(gdb) break some_breakpoint_in_32_bit_or_64_bit_code
(gdb) continue
[...]
Remote 'g' packet reply is too long: [...]
(gdb) disconnect # IMPORTANT STEP #1
(gdb) set architecture i386:x86-64
(gdb) target remote :1234 # IMPORTANT STEP #2
(gdb) continue
[1]: http://git.qemu.org/?p=qemu.git;a=commit;h=e3592bc9d841c397eeda87f0019fab94ff71004b
[2]: http://wiki.osdev.org/QEMU_and_GDB_in_long_mode#Workaround_1:_Reconnecting
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1686170/+subscriptions
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug 1686170] Re: qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options
2017-04-25 18:31 [Qemu-devel] [Bug 1686170] [NEW] qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options Alain Kalker
` (3 preceding siblings ...)
2019-12-27 3:08 ` Marek Dolata
@ 2020-04-26 7:17 ` chenhao
2021-05-05 6:57 ` Thomas Huth
5 siblings, 0 replies; 7+ messages in thread
From: chenhao @ 2020-04-26 7:17 UTC (permalink / raw)
To: qemu-devel
I had the same problem when I tried to run
[boot.asm](https://github.com/yifengyou/The-design-and-implementation-
of-a-64-bit-os/blob/master/code/c03/1/boot.asm).
i tested `qemu-system-x86_64` and `qemu-system-i386` with
[gdb_init_real_mode.txt](https://github.com/mhugo/gdb_init_real_mode/blob/master/gdbinit_real_mode.txt)
and
[target.xml](https://gist.githubusercontent.com/MatanShahar/1441433e19637cf1bb46b1aa38a90815/raw/2687fb5daf60cf6aa8435efc8450d89f1ccf2205/target.xml),
all faild.
my env:
1. deepin 15.11 x86_64
- qemu: QEMU emulator version 4.2.94 // qemu 5.0.0-rc4
- gdb: GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
1. ubuntu 20.04
- qemu: QEMU emulator version 4.2.0 (Debian 1:4.2-3ubuntu6)
- gdb: GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1686170
Title:
qemu-system-x86_64+gdb: unable to correctly disassemble "real mode"
(i8086) instructions after attaching to QEMU started with "-S -s"
options
Status in QEMU:
New
Bug description:
OS: Void Linux x86_64 (glibc)
QEMU version: 2.9.0
GDB version: 7.12.1
Problem description:
After I updated QEMU from version 2.8.1 to 2.9.0, I found that when I try to connect GDB to a running QEMU and try to debug Real mode machine code, I can no longer set architecture to 'i8086'.
To be able to connect to QEMU from GDB at all, I have to specify one of the 64 bit architectures, which among other things leads to incorrect disassembly listings. This makes debugging Real mode bootloaders, bootsectors and BIOS code much more difficult.
Steps to reproduce:
- Run QEMU
- In another terminal, run GDB
- In GDB, connect to QEMU
- In GDB, disassemble some Real mode machine code.
Expected results (from QEMU version 2.8.1):
[terminal #1]
$ qemu-system-x86_64 -S -s
[terminal #2]
(gdb) set architecture i8086
warning: A handler for the OS ABI "GNU/Linux" is not built
into this configuration
of GDB. Attempting to continue with the default i8086 settings.
The target architecture is assumed to be i8086
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x0000fff0 in ?? ()
(gdb) x/i $cs*16+$eip
0xffff0: ljmp $0xf000,$0xe05b
Actual results:
[terminal #1]
$ qemu-system-x86_64 -S -s
[terminal #2]
$ gdb -q
(gdb) set architecture i8086
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default i8086 settings.
The target architecture is assumed to be i8086
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
Remote 'g' packet reply is too long:
[..snip..]
Workarounds tried:
- Try different architecures
(gdb) set architecture i386:intel
The target architecture is assumed to be i386:intel
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
Remote 'g' packet reply is too long:
[..snip..]
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x000000000000fff0 in ?? ()
The last try finally allowed me to connect to QEMU, but as can be
expected from using an incorrect architecture setting, disassembly
output is complete gibberish:
(gdb) x/10i $cs*16+$rip
0xffff0: (bad)
0xffff1: pop %rbx
0xffff2: loopne 0xffff4
0xffff4: lock xor %dh,(%rsi)
0xffff7: (bad)
0xffff8: xor (%rbx),%dh
0xffffa: (bad)
0xffffb: cmp %edi,(%rcx)
0xffffd: add %bh,%ah
0xfffff: add %al,(%rax)
Discussion:
I think I've traced the problem to the following commit: "x86: Fix x86_64 'g' packet response to gdb from 32-bit mode."[1].
While I admire the effort to make life for people using GDB to debug QEMU VMs, I think the problem here is with GDB and can't be fixed entirely from the side of QEMU without breaking other features.
In fact, there is a well-known workaround to this problem published on
OSDev Wiki (Workaround #1)[2] which doesn't require patching either
QEMU or GDB. This workaround has worked for me using several previous
versions of QEMU.
$ gdb -q
(gdb) set architecture i8086
(gdb) target remote :1234
(gdb) break some_breakpoint_in_32_bit_or_64_bit_code
(gdb) continue
[...]
Remote 'g' packet reply is too long: [...]
(gdb) disconnect # IMPORTANT STEP #1
(gdb) set architecture i386:x86-64
(gdb) target remote :1234 # IMPORTANT STEP #2
(gdb) continue
[1]: http://git.qemu.org/?p=qemu.git;a=commit;h=e3592bc9d841c397eeda87f0019fab94ff71004b
[2]: http://wiki.osdev.org/QEMU_and_GDB_in_long_mode#Workaround_1:_Reconnecting
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1686170/+subscriptions
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug 1686170] Re: qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options
2017-04-25 18:31 [Qemu-devel] [Bug 1686170] [NEW] qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options Alain Kalker
` (4 preceding siblings ...)
2020-04-26 7:17 ` chenhao
@ 2021-05-05 6:57 ` Thomas Huth
5 siblings, 0 replies; 7+ messages in thread
From: Thomas Huth @ 2021-05-05 6:57 UTC (permalink / raw)
To: qemu-devel
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/141
** Changed in: qemu
Status: New => Expired
** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #141
https://gitlab.com/qemu-project/qemu/-/issues/141
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1686170
Title:
qemu-system-x86_64+gdb: unable to correctly disassemble "real mode"
(i8086) instructions after attaching to QEMU started with "-S -s"
options
Status in QEMU:
Expired
Bug description:
OS: Void Linux x86_64 (glibc)
QEMU version: 2.9.0
GDB version: 7.12.1
Problem description:
After I updated QEMU from version 2.8.1 to 2.9.0, I found that when I try to connect GDB to a running QEMU and try to debug Real mode machine code, I can no longer set architecture to 'i8086'.
To be able to connect to QEMU from GDB at all, I have to specify one of the 64 bit architectures, which among other things leads to incorrect disassembly listings. This makes debugging Real mode bootloaders, bootsectors and BIOS code much more difficult.
Steps to reproduce:
- Run QEMU
- In another terminal, run GDB
- In GDB, connect to QEMU
- In GDB, disassemble some Real mode machine code.
Expected results (from QEMU version 2.8.1):
[terminal #1]
$ qemu-system-x86_64 -S -s
[terminal #2]
(gdb) set architecture i8086
warning: A handler for the OS ABI "GNU/Linux" is not built
into this configuration
of GDB. Attempting to continue with the default i8086 settings.
The target architecture is assumed to be i8086
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x0000fff0 in ?? ()
(gdb) x/i $cs*16+$eip
0xffff0: ljmp $0xf000,$0xe05b
Actual results:
[terminal #1]
$ qemu-system-x86_64 -S -s
[terminal #2]
$ gdb -q
(gdb) set architecture i8086
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default i8086 settings.
The target architecture is assumed to be i8086
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
Remote 'g' packet reply is too long:
[..snip..]
Workarounds tried:
- Try different architecures
(gdb) set architecture i386:intel
The target architecture is assumed to be i386:intel
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
Remote 'g' packet reply is too long:
[..snip..]
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x000000000000fff0 in ?? ()
The last try finally allowed me to connect to QEMU, but as can be
expected from using an incorrect architecture setting, disassembly
output is complete gibberish:
(gdb) x/10i $cs*16+$rip
0xffff0: (bad)
0xffff1: pop %rbx
0xffff2: loopne 0xffff4
0xffff4: lock xor %dh,(%rsi)
0xffff7: (bad)
0xffff8: xor (%rbx),%dh
0xffffa: (bad)
0xffffb: cmp %edi,(%rcx)
0xffffd: add %bh,%ah
0xfffff: add %al,(%rax)
Discussion:
I think I've traced the problem to the following commit: "x86: Fix x86_64 'g' packet response to gdb from 32-bit mode."[1].
While I admire the effort to make life for people using GDB to debug QEMU VMs, I think the problem here is with GDB and can't be fixed entirely from the side of QEMU without breaking other features.
In fact, there is a well-known workaround to this problem published on
OSDev Wiki (Workaround #1)[2] which doesn't require patching either
QEMU or GDB. This workaround has worked for me using several previous
versions of QEMU.
$ gdb -q
(gdb) set architecture i8086
(gdb) target remote :1234
(gdb) break some_breakpoint_in_32_bit_or_64_bit_code
(gdb) continue
[...]
Remote 'g' packet reply is too long: [...]
(gdb) disconnect # IMPORTANT STEP #1
(gdb) set architecture i386:x86-64
(gdb) target remote :1234 # IMPORTANT STEP #2
(gdb) continue
[1]: http://git.qemu.org/?p=qemu.git;a=commit;h=e3592bc9d841c397eeda87f0019fab94ff71004b
[2]: http://wiki.osdev.org/QEMU_and_GDB_in_long_mode#Workaround_1:_Reconnecting
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1686170/+subscriptions
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-05-05 7:15 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-25 18:31 [Qemu-devel] [Bug 1686170] [NEW] qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options Alain Kalker
2017-04-26 15:24 ` [Qemu-devel] [Bug 1686170] " Alain Kalker
2017-07-10 16:55 ` Duane Voth
2018-05-12 12:10 ` Vladislav K. Valtchev
2019-12-27 3:08 ` Marek Dolata
2020-04-26 7:17 ` chenhao
2021-05-05 6:57 ` Thomas Huth
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.