diff options
Diffstat (limited to 'open_issues/debugging_gnumach_startup_qemu_gdb.mdwn')
| -rw-r--r-- | open_issues/debugging_gnumach_startup_qemu_gdb.mdwn | 165 |
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 |