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
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
|
[[!meta copyright="Copyright © 2010, 2011, 2013, 2014 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]]
[[!toc]]
# Memory Map
## IRC, freenode, #hurd, 2010-06 (?)
<jkoenig> is there a way to get gdb to map addresses as required when
debugging mach with qemu ?
<jkoenig> I can examine the data if I manually map the addresses th
0xc0000000 but maybe there's an easier way...
<youpi> jkoenig: I haven't found a way
<youpi> I'm mostly using the internal kdb
## 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
# <a name="multiboot">Multiboot</a>
See also [[hurd/running/qemu#multiboot]].
## IRC, freenode, #hurd, 2014-02-24
<congzhang> hi, will grub load mach kernel to fix address? and which
address?
<congzhang> I want to use qemu gdb support to debug mach
<congzhang> need add-symble-file to right address
<youpi> congzhang: see objdump gnumach
<youpi> grub simply follows what's provided by the ELF format of the ELF
file
<nalaginrut> I think it's default value of _start in ELF, right?
<nalaginrut> hmm...the actual entry point should plus the size of
multi_boot header, at least 0xc...
<congzhang> youpi: I try that, but not works
<congzhang> I start qemu with -s
<congzhang> the /bin/console was very easy to cause black death, and I want
to use gdb to check whether the mach is death
<congzhang> I will try again later
<congzhang> Anyone know some tutorial to debug mach with qemu?
<nalaginrut> for better debug, I suggest bochs
<nalaginrut> although it's slower
<congzhang> nalaginrut: maybe it's my problem, I did not do the right thing
<congzhang> qemu with kvm was great.
<nalaginrut> qemu with kvm is cool to run, but not so cool for debug kernel
<nalaginrut> anyway, it's personal taste
<nalaginrut> you may use gdb for that
<nalaginrut> for bochs, you don't have to use external debugger
<congzhang> thanks for explain
|
