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
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
|
[[!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
# Multiboot
See also discussion about *multiboot* on [[arm_port]].
## IRC, freenode, #hurd, 2013-10-09
<matlea01> I was just wondering - once gnumach is compiled and I have the
gnumach elf, is that bootable? I.e. can I use something like
"qemu-system-i386 -kernel gnumach"?
<kilobug> matlea01: you need something with multiboot support (like grub)
to provide the various bootstrap modules to the kernel
<matlea01> Ah, I see
## 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
<congzhang> does anyone succeed boot hurd with qemu multiboot boot
function?
<congzhang> with -kernel and -initrd command line parameter
<nalaginrut> I boot it with grub, in qemu, it's fine. Then I moved to
physical machine
<congzhang> boot with grub work for me too
<congzhang> I want to know whether it is possible to boot from qemu
directly
<congzhang> qemu can directly load kernel and hurd module for linux
<congzhang> nalaginrut: can you help to test whether hurd-console service
start will cause hurd black death?
<nalaginrut> I know qemu can boot Linux without MBR, but I don't know if
it's true for Hurd too
<nalaginrut> congzhang: I'm busy for other works now ;-)
<congzhang> ok, thks:)
<youpi> qemu's multiboot options don't seem to allow providing
ext2fs.static and ld.so, so I don't think it's possible
<congzhang> I try to do this, because hurd hurd-console cause system to
death very high frequency
<youpi> (because qemu doesn't implement all of multiboot)
<congzhang> qemu help show that's possible, -initrd support multi module
and parameter
<congzhang> en, I will check with them later
<youpi> how do you pass parameters to modules?
<youpi> ah, right, it's after the file name
<youpi> well, then simply try to pass the kernel, and the two modules
<youpi> with the same option as in the grub config templates
<youpi> it's fortunate that neither ext2fs nor exec need a comma on their
command line...
|
