On Tue, Mar 21, 2023 at 5:19 PM Luca <l...@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
