From 1c8909017d006c8e4afeea6d1a1efdebe26fc6b0 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 15 Jul 2011 22:46:18 +0200 Subject: IRC. --- .../debugging_gnumach_startup_qemu_gdb.mdwn | 116 +++++++++++++++++++++ 1 file changed, 116 insertions(+) create mode 100644 open_issues/debugging_gnumach_startup_qemu_gdb.mdwn (limited to 'open_issues/debugging_gnumach_startup_qemu_gdb.mdwn') 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..e3a6b648 --- /dev/null +++ b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn @@ -0,0 +1,116 @@ +[[!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 + + 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 -- cgit v1.2.3