rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

1 files changed, 0 insertions, 165 deletions

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