Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port

[Sergey Bugaev]

On Tue, Mar 21, 2023 at 3:52 PM Luca <luca@orpolo.org> wrote:
>
> Il 21/03/23 13:37, Sergey Bugaev ha scritto:
> > On Tue, Mar 21, 2023 at 3:20 PM Luca <luca@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 :)

Ah, so you're saying the com port works, but VGA console (or whatever
it's called, I don't have a clue about hardware as you might have
noticed...) support is buggy? That makes sense, I will try com0, thank
you!

> >> #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.

The gnumach patch adding the API is this one:
https://mail.gnu.org/archive/html/bug-hurd/2023-03/msg00085.html

Every thread needs to have its own values of fs_base / gs_base, and
you need to store/restore them on context switch by accessing the
appropriate MSR. There's also the swapgs instruction that I'm told is
useful if you also use gs for kernel's own needs (such as per-CPU
data).

> > 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...

Yes, and this is what main () in module-bootstrap-hello does -- it
parses the command-line arguments, finds the device master port
(passed as --device-master-port arg), then calls (pseudocode)

mach_console = device_open ("console");
stderr = mach_open_devstream (mach_console, "w");

>From that point on, stderr goes to the Mach console. But glibc cannot
do that on its own (it's up to the user program to declare it has a
command-line arg specifying the device master port name...), so that
won't happen before we get to main ().

We should probably just do

#ifdef __LIBC_NO_TLS
if (__LIBC_NO_TLS ())
  __builtin_trap ();
#endif

in abort ().

Sergey