IRC channel logs

2023-05-04.log

back to list of logs

<biblio>luckyluke: I debugged 64-bit version and compared with 32-bit. "user_bootstrap()" function in bootstrap.c is not invoked. Therefore, "while (! info.done)" is waiting indefinitely in "boot_script_exec_cmd(...)". Any clue, how can I view page-fault, other errors, or inspect TSS descriptor ?
<luckyluke>uhm, that's quite strange, nothing should work if user_bootstrap is not run, but with the latest version I can at least run some simple tests as bootstrap tasks
<luckyluke>b1cddee81d48a7fe2350d334aa756999fd265920 seems to work, with latest mig
<gnucode>How can ya'll debug a 64 bit version...if the 64 bit port is not yet done?
<biblio>luckyluke: I tested 61dfca567e982f2d6a0a25b04e9eb78adcaac370. I will test b1cddee81d48a7fe2350d334aa756999fd265920.
<luckyluke>gnucode: I use either some small static executable for the 64-bit userspace, or a 32-bit ramdisk for the 32-bit userspace on the 64-bit kernel
<biblio>gnucode: you can start qemu with -s -S and start gdb and type "target remote :1234" it will help you to debug. example: kvm -s -S -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic,model=e1000 -drive file=$(echo debian-hurd*.img),cache=writeback -m 1G
<biblio>gnucode: gdb gnumach (specify executable in gdb inside build dir)
<luckyluke>biblio: 31dd30a94a682955c3c9e2f42252b4a07687067a seems to break the 32-bit userspace
<luckyluke>with the commit just before (660bc8ab3813737b3857648b7ec60d88494aeed1) I can still run my ramdisk test
<biblio>luckyluke: I could not cross-build 32-bit HURD on 64-bit linux due to _Static_assert. So, to test 32-bit I build inside hurd qemu.
<luckyluke>did you reocmpile mig also?
<biblio>luckyluke: I am using mig 4c0f2ff0a1432f7e1794cf29b1a4667e3a0f8f89
<biblio>luckyluke: I am trying to recompile mig also and test.
<luckyluke>ok, same version I'm using
<luckyluke>I'm using this to cleanly recompile gnumach and mig on linux https://gitlab.com/luckyd/gnumach/-/blob/prepare64_wip/scripts/build-gnumach-mig.sh
<biblio>luckyluke: i just tested b1cddee81d48a7fe2350d334aa756999fd265920 from https://git.savannah.gnu.org/git/hurd/gnumach.git/ same in qemu
<biblio>luckyluke: i will test build-gnumach-mig.sh
<luckyluke>ah, another thing might be the console, the 64-bit kernel has some issues if you use the graphical qemu interface
<luckyluke>I'm using the serial console with console=com0 at cmdline for now
<biblio>luckyluke: ok noted. I saw in few places mov instead of movl (I dont think it is an issue)
<biblio>luckyluke: also in some assembly %e** instead of %r for 64 bit.
<luckyluke>mov is translated to the correct variant (movq/movl) usually by gcc
<biblio>luckyluke: yes I saw printf of sizeof(long) = 8 so it should be fine.
<biblio>luckyluke: i just finished intel x86 guide. but still need to apply the knowledge :)
<biblio>luckyluke: thanks for the info. I will check further.
<luckyluke>IIRC in some selected cases the %e** variant is also needed, but should be just a few
<Arsen>hey, why was hurd ported to amd64 by bootstrapping off of a 32 bit multiboot2 instead of porting multiboot2 to amd64 too?
<Arsen>(i'm asking because i'd like to do the latter for an unrelated project and so am curious about prior experience)
<luckyluke>Arsen: I'd say mostly to reuse the code from the 32-bit version of gnumach
<Arsen>wdym? the bootstrap code is a few hundred bytes of asm that gets into long mode and at that point none of the existing code is useful AFAIK
<Arsen>(existing binary code that is - the C remains useful naturally)
<luckyluke>the code to make use of the multiboot structures, decode info about memory region and bootstrap modules
<luckyluke>I think multibuut2 uses different structures, but I've never used it
<Arsen>it does
<Arsen>#define MULTIBOOT_MAGIC 0x1BADB002
<Arsen>ah indeed, this is MB1
<Arsen>hence no MB2 port to amd64 ;)
<Arsen>okay, I'd still like to pursue that project eventually
<luckyluke>great :)
<biblio>luckyluke: yes, it works in serial (not with vga).
<biblio>luckyluke: console=com0