[[!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 (?) is there a way to get gdb to map addresses as required when debugging mach with qemu ? I can examine the data if I manually map the addresses th 0xc0000000 but maybe there's an easier way... jkoenig: I haven't found a way I'm mostly using the internal kdb ## IRC, freenode, #hurd, 2011-07-14 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? hm not sure let me try mcsim: works for me :/ it works without my patch, but with it qemu hangs oh, i thought it worked when not using continue with my patch I can reach idt_init only using next and without all works fine mcsim: are you sure you correctly built it with debugging symbols ? I've written in /etc/dpkg/buildflags.conf SET CFLAGS -g3 -O0 hm i have internal kvm errors actually mcsim: do you use kvm ? mcsim: and why break on those functions ? i'm not sure the address space is already fine at this point no. I don't have hardware virtualisation support. hm actually, you won't be able to use gdb i just remembered how gnumach is linked and mapped :/ the addresses in the elf image are low addresses, matching the image as it is loaded by the boot loader I was wondering why qemu hangs. then the kernel uses segmentation to map itself at 2 (or 3 previously) GiB well, if the addresses are wrong, your breakpoints are wrong i even wonder how it can work when stepping i don't have the issue with x15 because of its linker script Are there any ways of such debugging without qemu? i don't think so as antrik told you, the in kernel debugger needs many services running before being usable you'll have to use printf, and there may be steps during bootstrap when even that isn't available So I need computer with hardware virtualisation? well, of course stepping works, since the breakpoints are relative no kvm has nothing to do with the problem it's just that the problem appears differently with kvm enabled ok. thank you. good luck braunr: would it be hard to "fix" gnumach to avoid the segmentation magic?... antrik: because of the linux drivers, it may or alternatively, implement something in GDB to deal with that?... antrik: i didn't study that part enough to know for sure uhm... why would the Linux drivers depend on that? does Linux also do such magic?... well it should simply be a matter of shifting the address by a fixed offset antrik: linux drivers rely on physical memory being allocated through kmalloc so there must be a direct mapping between virtual kernel memory and physical memory they don't specifically need that segmentation settings so if you remove the offset implemented through segmentation, you have to replace it with page mapping and i don't know how much needs to be done for that you also need to link the kernel differently hm, OK so adding GDB support for the offset would probably be easier... yes but using the offset must only be done once segmentation is set up so you must break after gdt_init not on it mcsim: why do you break on these functions btw ? I just wanted to find out why qemu hangs yes but why those ? I found out that before gdt_init all workes fine, but after qemu hangs. So idt_init is just the next function ok and does your patch change something to how segmentation is initialized ? now no try to build it with the regular cflags i don't know if gnumach can work with -O0 I've tried. But all the same Regular are -g -O2 can you make your patch available ? yes it is available in gnumach repository at savannah tree mplaneta/libbraunr/master well, if the segmentation stuff is the thing GDB has problems with, I don't see how it can work without your patch... without ? well, the patch shouldn't affect the segmentation... so I don't see how it can make a difference he said qemu hanged so let's not introduce gdb yet qemu can hang for other reasons oh, right, without GDB... though if that's what he meant, his statement was very misleading at least # Multiboot See also [[hurd/running/qemu#multiboot]]. ## IRC, freenode, #hurd, 2014-02-24 hi, will grub load mach kernel to fix address? and which address? I want to use qemu gdb support to debug mach need add-symble-file to right address congzhang: see objdump gnumach grub simply follows what's provided by the ELF format of the ELF file I think it's default value of _start in ELF, right? hmm...the actual entry point should plus the size of multi_boot header, at least 0xc... youpi: I try that, but not works I start qemu with -s the /bin/console was very easy to cause black death, and I want to use gdb to check whether the mach is death I will try again later Anyone know some tutorial to debug mach with qemu? for better debug, I suggest bochs although it's slower nalaginrut: maybe it's my problem, I did not do the right thing qemu with kvm was great. qemu with kvm is cool to run, but not so cool for debug kernel anyway, it's personal taste you may use gdb for that for bochs, you don't have to use external debugger thanks for explain