summaryrefslogtreecommitdiff
path: root/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn
blob: 3faa56fc5624a87d824b990d4700da5d75bfdf4a (plain)
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
[[!meta copyright="Copyright © 2010, 2011, 2013 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