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
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
|
[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
[[!meta title="Debugging GNU Mach's startup in QEMU with GDB"]]
[[!tag open_issue_gdb open_issue_gnumach]]
# IRC, freenode, #hurd, 2011-07-14
<mcsim> Hello. I have problem with debugging gnumach. I set 2 brakepoints
in file i386/i386at/model_dep.c on functions gdt_init and idt_init. Then
I start qemu with patched gnumach kernel and stop at gdt_init. When I
enter command "continue" in gdb, qemu hangs. But when I go step by step,
using command "next", I freely reach idt_init. What can cause this
problem?
<braunr> hm
<braunr> not sure
<braunr> let me try
<braunr> mcsim: works for me :/
<mcsim> it works without my patch, but with it qemu hangs
<braunr> oh, i thought it worked when not using continue
<mcsim> with my patch I can reach idt_init only using next
<mcsim> and without all works fine
<braunr> mcsim: are you sure you correctly built it with debugging symbols
?
<mcsim> I've written in /etc/dpkg/buildflags.conf SET CFLAGS -g3 -O0
<braunr> hm
<braunr> i have internal kvm errors actually
<braunr> mcsim: do you use kvm ?
<braunr> mcsim: and why break on those functions ?
<braunr> i'm not sure the address space is already fine at this point
<mcsim> no. I don't have hardware virtualisation support.
<braunr> hm actually, you won't be able to use gdb
<braunr> i just remembered how gnumach is linked and mapped :/
<braunr> the addresses in the elf image are low addresses, matching the
image as it is loaded by the boot loader
<mcsim> I was wondering why qemu hangs.
<braunr> then the kernel uses segmentation to map itself at 2 (or 3
previously) GiB
<braunr> well, if the addresses are wrong, your breakpoints are wrong
<braunr> i even wonder how it can work when stepping
<braunr> i don't have the issue with x15 because of its linker script
<mcsim> Are there any ways of such debugging without qemu?
<braunr> i don't think so
<braunr> as antrik told you, the in kernel debugger needs many services
running before being usable
<braunr> you'll have to use printf, and there may be steps during bootstrap
when even that isn't available
<mcsim> So I need computer with hardware virtualisation?
<braunr> well, of course stepping works, since the breakpoints are relative
<braunr> no
<braunr> kvm has nothing to do with the problem
<braunr> it's just that the problem appears differently with kvm enabled
<mcsim> ok. thank you.
<braunr> good luck
<antrik> braunr: would it be hard to "fix" gnumach to avoid the
segmentation magic?...
<braunr> antrik: because of the linux drivers, it may
<antrik> or alternatively, implement something in GDB to deal with that?...
<braunr> antrik: i didn't study that part enough to know for sure
<antrik> uhm... why would the Linux drivers depend on that? does Linux also
do such magic?...
<braunr> well it should simply be a matter of shifting the address by a
fixed offset
<braunr> antrik: linux drivers rely on physical memory being allocated
through kmalloc
<braunr> so there must be a direct mapping between virtual kernel memory
and physical memory
<braunr> they don't specifically need that segmentation settings
<braunr> so if you remove the offset implemented through segmentation, you
have to replace it with page mapping
<braunr> and i don't know how much needs to be done for that
<braunr> you also need to link the kernel differently
<antrik> hm, OK
<antrik> so adding GDB support for the offset would probably be easier...
<braunr> yes
<braunr> but using the offset must only be done once segmentation is set up
<braunr> so you must break after gdt_init
<braunr> not on it
<braunr> mcsim: why do you break on these functions btw ?
<mcsim> I just wanted to find out why qemu hangs
<braunr> yes but why those ?
<mcsim> I found out that before gdt_init all workes fine, but after qemu
hangs. So idt_init is just the next function
<braunr> ok
<braunr> and does your patch change something to how segmentation is
initialized ?
<mcsim> now
<mcsim> no
<braunr> try to build it with the regular cflags
<braunr> i don't know if gnumach can work with -O0
<mcsim> I've tried. But all the same
<mcsim> Regular are -g -O2
<braunr> can you make your patch available ?
<mcsim> yes
<mcsim> it is available in gnumach repository at savannah
<mcsim> tree mplaneta/libbraunr/master
<antrik> well, if the segmentation stuff is the thing GDB has problems
with, I don't see how it can work without your patch...
<braunr> without ?
<antrik> well, the patch shouldn't affect the segmentation... so I don't
see how it can make a difference
<braunr> he said qemu hanged
<braunr> so let's not introduce gdb yet
<braunr> qemu can hang for other reasons
<antrik> oh, right, without GDB...
<antrik> though if that's what he meant, his statement was very misleading
at least
|
