Re: [RFC][PATCH] _UC_TLSBASE for all ports

[manu%netbsd.org@localhost (Emmanuel Dreyfus)]

Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

> Assuming we go with the "no spec" stance, I think the truth would be
> more like "trying to use contexts across thread boundaries is
> inherently MD, working the way you expect on ports $LIST1, working this
> other way on ports $LIST2, and this third way on ports $LIST3; you're
> depending on behaviour not portable between CPU architectures".

Yes and no. Indeed there are MD bits here, but pthread and swapcontext()
are MI features. One can resonabily expect our MI features to work the
same way on all ports. At least it should be our goal, as far as I
undertstand NetBSD core values.

Then there is the problem that no spec tells us what swapcontext()
should do with pthread private context, as returned by pthread_self().
Obviously there are two possible behaviors:
1- left pthread private context untouched, as Linux does, and perhaps
our powerpc ports, I am not sure.
2- let user change the pthread private context, as it is the default on
NetBSD (except powerpc ports, not sure).

Behavior 1 seems to have real applications. I am not sure behavior 2 can
lead to anything but SIGSEGV, but perhaps someone reimplementing a new
thread library could enjoy that, I cannot tell. 

A nice way to cope with unspecified behavior is to offer
user-configurable options. Our amd64, arm, hppa, i386, m68k, and vax
based ports offer such an option called _UC_TLSBASE. alpha offer the
same feature with a different name: _UC_UNIQUE.

My proposal is to add _UC_TLSBASE as a synonym of _UC_UNIQUE for alpha,
and to add _UC_TLSBASE for CPU that miss it: sh3, sparc, sparc64,
powerpc. Adding the option is a 4 lines patch for a given CPU, this is
just about adding a test on _UC_TLSBASE before restoring the pthread
private pointer.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu%netbsd.org@localhost