[[!meta copyright="Copyright © 2011 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]]


# 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