<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 discussion about multiboot on arm port.
<matlea01> I was just wondering - once gnumach is compiled and I have the gnumach elf, is that bootable? I.e. can I use something like "qemu-system-i386 -kernel gnumach"? <kilobug> matlea01: you need something with multiboot support (like grub) to provide the various bootstrap modules to the kernel <matlea01> Ah, I see
<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 <congzhang> does anyone succeed boot hurd with qemu multiboot boot function? <congzhang> with -kernel and -initrd command line parameter <nalaginrut> I boot it with grub, in qemu, it's fine. Then I moved to physical machine <congzhang> boot with grub work for me too <congzhang> I want to know whether it is possible to boot from qemu directly <congzhang> qemu can directly load kernel and hurd module for linux <congzhang> nalaginrut: can you help to test whether hurd-console service start will cause hurd black death? <nalaginrut> I know qemu can boot Linux without MBR, but I don't know if it's true for Hurd too <nalaginrut> congzhang: I'm busy for other works now ;-) <congzhang> ok, thks:) <youpi> qemu's multiboot options don't seem to allow providing ext2fs.static and ld.so, so I don't think it's possible <congzhang> I try to do this, because hurd hurd-console cause system to death very high frequency <youpi> (because qemu doesn't implement all of multiboot) <congzhang> qemu help show that's possible, -initrd support multi module and parameter <congzhang> en, I will check with them later <youpi> how do you pass parameters to modules? <youpi> ah, right, it's after the file name <youpi> well, then simply try to pass the kernel, and the two modules <youpi> with the same option as in the grub config templates <youpi> it's fortunate that neither ext2fs nor exec need a comma on their command line...