PERFORCE change 50188 for review
Doug Rabson
dfr at nlsystems.com
Sat Apr 3 00:00:16 PST 2004
On Friday 02 April 2004 20:38, Julian Elischer wrote:
> Doug Rabson wrote:
> > On Friday 02 April 2004 19:31, Julian Elischer wrote:
> >>Doug Rabson wrote:
> >>>On Fri, 2004-04-02 at 17:47, Julian Elischer wrote:
> >>>>And the crowd goes wild...
> >>>
> >>>I'm not convinced that rtld is quite right yet. In particular,
> >>>stuff like:
> >>> int __thread x[10];
> >>> &x[5];
> >>>
> >>>is probably broken.
> >>>
> >>>FWIW, our binutils doen't support the Sun abi at all...
> >>
> >>hmmm I wonder if it's planned or if we have to do it..
> >
> > Personally, I don't see the point. The GNU abi is smaller and
> > faster and will be better maintained by the gnu people over time.
> > There isn't any choice for any of the other platforms, including
> > amd64 (which uses a gnu-style abi with %fs:0 == %fs).
>
> So we are screwed for amd64 basically.
>
Yes.
>
> But the reason the sun ABI axists is because on a PC using %gs as a
> segment register for thread identification, you cannot use the GNU
> model unless you are using 1:1 threads. You need to be able to
> change the place the pointer points from userland. Obviously this
> requires a syscall as changing a [gl]dt entry can not be done by a
> user process. This means that every context switch would require a
> syscall which defeats the entire point of using M:N threads.
>
> The SUN API allows the destination of the %gs:0 to be changes at
> runtime by the user this allowing the UTS to switch threads "on the
> fly" without going back to the kernel.
It is not true that the GNU model can only work for 1:1 threading. I can
think of at least two ways of arranging for %gs:0==%gs without adding
significant overhead to the userland thread switch code and without
using syscalls in the common path.
>
> Processors that have a "thread pointer" register are ok because the
> UTS can just change it whenever it switches threads. Unfortunatly the
> X86 requires that we use a priviledged operation.
> The only thing I can see as a possibility is if we make a special
> trap into the kernel (bypassing all the normal syscall code)
> that takes a single register as an argument and puts it into the
> segment register descriptor pointed to by %gs after checking it VERY
> quickly, and returns.. it may be possible to get in and out of the
> kernel quick enough that we don't lose performance.
This might work, e.g. if we pre-allocate a per-cpu GDT entry for this
purpose and this special trap merely changes the base address of this
pre-initialised GDT.
I've just taken a look at the latest binutils cvs and gas does not have
any support for the relocations required for the Sun abi (e.g.
x at DTLNDX, x at TLSPLT). Given that the code relaxation optimisations which
are to be performed by the linker are much trickier for the Sun abi, I
doubt that ld supports it either. Lets just look at the pros and cons
here:
Sun ABI
Pros Cons
Works with todays libpthread We would need to branch binutils and
maintain that branch forever
Code size and speed are poor
We would be using a mode of the compiler
which no-one else really cares about
GNU ABI
Pros Cons
Supported by binutils and gcc today We have to add ~5 lines of code to
the userland thread switch
Small and fast code - easy to optimise
at link time
Everyone else using gnu tools uses
this mode so its well maintained
More information about the freebsd-threads
mailing list