<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
<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
See also qemu.
<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