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