On Tue, Mar 21, 2023 at 3:20 PM Luca <l...@orpolo.org> wrote: > did you add $(task-resume) in the boot script?
$(prompt-task-resume), yes. But (see my later mail) Mach hits a page fault trying to printf "task loaded:", it never gets to resuming the task. This must be due to some difference in how we're running QEMU (i.e. what machine it emulates). FWIW mine QEMU cmdline is: qemu-system-x86_64 -m 1G -cdrom ./rootfs.iso (so maybe try that to reproduce it like that?). I can send you my rootfs.iso too, if that's needed. > #2 0x0000000000400645 in abort () at abort.c:64 > #3 0x0000000000400586 in _dl_start () at > ../sysdeps/mach/hurd/x86/init-first.c:267 > #4 0x00000000004ae9f7 in __thread_set_state > (target_thread=target_thread@entry=5, > flavor=flavor@entry=7, new_state=new_state@entry=0xbfffff30, > new_stateCnt=new_stateCnt@entry=4) > at > /home/sergey/dev/crosshurd64/src/glibc/build/mach/RPC_thread_set_state.c:124 > #5 0x000000000040c529 in _hurd_tls_new (tcb=0x514cc0 <__init1_tcbhead>, > child=5) > at ../sysdeps/mach/hurd/x86_64/tls.h:166 > #6 _hurd_tls_init (tcb=0x514cc0 <__init1_tcbhead>) at > ../sysdeps/mach/hurd/x86_64/tls.h:187 🎉 — that is the (for now) expected crash on trying to set fs_base. Please implement the proposed i386_fsgs_base_state in gnumach to make glibc proceed further :) As for the actual crash inside hurd_self_sigstate () — maybe abort () needs a simpler implementation for the __LIBC_NO_TLS () case, one that does not involve sigstate. But it doesn't really matter much — abort was called to crash the task, it did crash, the job is done :) Sergey