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

[Sergey Bugaev]

On Tue, Mar 21, 2023 at 5:19 PM Luca <luca@orpolo.org> wrote:
> > 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).
>
> I see there are also the rdfsbase/wrfsbase/rdgsbase/wrfgsbase
> instructions which would simplify a lot this part, but they are
> relatively new (~10 years)... I guess we need to handle also the case
> using MSRs/swapgs, which seems quite complicated if made efficient, as
> it requires to keep track of the GS state on each trap entry. I'll try
> to have a simple implementation that works, and eventually optimize it
> later.
>
> Also, as far as I understand, currently per-cpu data are stored in
> arrays indexed with the cpu number, so maybe we can't take advantage of
> swapgs anyway.

But how does a core know its CPU number?

> >  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 ().
>
> I don't know if taking the args from the stack is done only for
> bootstrap modules

I don't think there's anything that prevents you from starting
non-bootstrap tasks like this (with on-stack args instead of the Hurd
exec_startup protocol), but it's a good hint that we might be a
startup task and may want to open the console, yes.

> but maybe it could be a trigger to open the console
> early, at least for the time being.

But the issue is not with knowing whether we are a startup task or
not, it's with getting the device master port, which is then used to
open the Mach console. In the bootscript, we tell Mach to insert the
port into the task, and format its name into the argv of the bootstrap
task (e.g. --device-master-port=1). The user logic that runs inside
the task then parses the argv and finds the port name, and then it can
give it to glibc. But this interface is between the boot script, Mach,
and the program; glibc is not aware of it. I could have chosen to name
the argument --device-port-name, or make it a positional argument, or
anything else, really. glibc can't know which of the arguments names
the device master port (quite possibly none of them do), and it's not
glibc's business to imply any semantics about, and try to parse the
argv, beyond argv[0] that is.

This would've been easier if we could pass the port name as an env
variable, then we could pick some predefined name (e.g.
DEVICE_MASTER_PORT) and have glibc pick it up early. But I don't think
there is a way to set env in boot scripts, nor is it worth it, really.

What would work though, and sounds worth it, is hooking this up with
the mach_print debug syscall.

Sergey