Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn"

This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1.

1 files changed, 165 insertions, 0 deletions

diff --git a/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn
new file mode 100644
index 00000000..68a04bfb
--- /dev/null
+++ b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn
@@ -0,0 +1,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