Re: [VERY RFC PATCH] x86_64: Rework storing segment registers

[Sergey Bugaev]

On Thu, Jun 15, 2023 at 8:02 PM Luca <luca@orpolo.org> wrote:
> That's a bit strange, with my kernel I can now successfully end the
> second stage, and without these warnings. Strangely, I don't see the
> "Setting up translators: " line...

Check /debootstrap/debootatrap.log :)

The output I posted was from both debootstrap std{out,err} and the
log, interleaved. I'm launching tail -f /debootstrap/debootatrap.log
in parallel with deboostrap itself, following Samuel's instructions.

> > +#if !defined(__x86_64__) || defined(USER32)
>
> I'm wondering if we could simplify this case by defining USER32 also on
> i386.

Perhaps, but then you'd need to go over the other usages of USER32 and
verify they don't imply x86_64.

> > +#if defined(__x86_64__) && !defined(USER32)
> > +struct i386_saved_fsgs_base_state {
> > +     unsigned long   fsbase;
> > +     unsigned long   gsbase;
> > +};
> > +#endif
> > +
>
> These can maybe be placed in the i386_machine_state below

Yeah, that'd probably be better.

> Why did you remove these? The idea was that they could now be empty on
> full 64-bit, and encapsulating the segment handling code for 32-bit,
> which is repeated in various places... One addition could also be to set
> the kernel segments after saving the user ones, or are there some more
> variations of them?

Because there's no longer a need to do anything special for fs/gs,
they are now handled the same way as es/ds, namely ifdef'ed out on
!USER32.

Maybe it would make sense to define new macros like PUSH_SEGS and
POP_SEGS that would push/pop all of (ds, es, fs, gs), but that'd be a
separate change from this patch.

Sergey