> This comes up because it interferes with a potential use of %gs we have
> in mind for linuxthreads. That is, %gs is set up at the birth of the
> thread to point to the thread-local data structures, and is thereafter
> left alone. Currently the code to derive this base address from the
> stack pointer is quite complex, since we can use nothing so simple as
> is used in the kernel. This would simplify that code and free up one
> register in all of the thread functions at the expense of an additional
> cycle at access time decoding the segment prefix.
AFAIK it causes not only an extra cycle, but also instruction queue flush
at least on PPro.
> Whether this is a
> win overall is not yet known for certain, but it seems promising.
Does this mean every program using threads needs to have its own LDT
and that starting a new thread involves yet another syscall to set up
his LDT entry?
On the other hand, it doesn't mean setting both FS and GS to USER_DS
is sane -- I think it should be either set to the null descriptor (references
to FS/GS in signal handlers are usually bogus, especially if these registers
are not preserved) or contain the same values as in the interrupted program.
> + seg = frame->sc.fs;
> + if ((seg & 0xfffc)
> + && (seg & 4) != 4
> + && (seg & 3) != 3)
> + seg = __USER_DS;
> + loadsegment(fs,seg);
> +
> + seg = frame->sc.gs;
> + if ((seg & 0xfffc)
> + && (seg & 4) != 4
> + && (seg & 3) != 3)
> + seg = __USER_DS;
> + loadsegment(gs,seg);
Null descriptor should be used instead of __USER_DS in case the original value
is wrong.
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "IBM = Inferior, But Marketable"- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html