blob: bbb872321f86bf358aa2eb5f6e67efb0c09b2785 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
|
graphic: 0.918
x86: 0.915
kernel: 0.908
debug: 0.867
semantic: 0.837
architecture: 0.833
performance: 0.792
user-level: 0.791
boot: 0.743
files: 0.725
device: 0.719
mistranslation: 0.717
permissions: 0.639
network: 0.637
ppc: 0.637
PID: 0.622
socket: 0.614
vnc: 0.533
VMM: 0.526
risc-v: 0.523
i386: 0.523
register: 0.507
hypervisor: 0.501
assembly: 0.490
peripherals: 0.484
arm: 0.444
KVM: 0.443
TCG: 0.335
virtual: 0.308
QEMU does not communicate properly with GDB with a 64 bit guest
I have been trying to figure out why I cannot debug a 64 bit kernel of my own invention.
I launch qemu-system-x86_64 with the -s -S flags, we also specify -cpu core2duo -vga std and a -hda with an ext2 FS holding our multiboot kernel and GRUB2.
When I try to set breakpoints and "continue" in GDB (7.2) using the very latest HEAD (b6601141cd2a170dfe773987b06f716a190ea7e0) or 0.12.0 or 0.12.5 or 13.0.rc0 or 13.0.rc1, I get failures of the same nature:
0x0000000000000000 in ?? ()
(gdb) break main
Breakpoint 1 at 0x101730: file src/kernel/init.c, line 18.
(gdb) c
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000000000000000 in ?? ()
(gdb)
Note that in this case, main lies in 64 bit mode. However, trying to break on _start yields virtually the same effect and _start is 32 bit code.
By doing a git bisect, I managed to narrow the commit that introduced this bug to 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1. Reverting this commit on HEAD seemingly fixed the problem for both the 32 bit and 64 bit cases.
I might be doing something incorrectly on my end but this seemed to fix the problem.
Perhaps the pertinent thing to do would be to revert 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1 as it seems to do nothing but break things unless, of course, this would only break something that I am not aware of further.
Can you still reproduce this problem with the latest version of QEMU, or can we close this ticket nowadays?
[Expired for QEMU because there has been no activity for 60 days.]
|