Il 21/03/23 13:37, Sergey Bugaev ha scritto:
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.
Ah yes, if I use the GUI I see what you mean. You could try to use
-nographic on qemu and console=com0 to gnumach cmdline :)
#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 :)
wow! I'll have a look.
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 :)
I saw in the past that some errors are automatically printed to the
console by the bootstrap modules, I guess it would be useful also in
this case? IIRC there is some helper to open the console device if
stderr is not set, or something similar...
Luca