Re: TLS, was Re: Getting the ol' Macintosh LC475 modernized

[Finn Thain <fthain@telegraphics.com.au>]

On Thu, 22 Aug 2013, Thorsten Glaser wrote:

> Finn Thain dixit:
> 
> we could do other sensible things (64-bit time_t, register passing of 
> arguments, other legacy cleanup).

Probably adding syscalls could fix the 32-bit time_t without breaking 
anything (given symbol versioning in libc).

Fixing everything (as in a new ABI) means simultaneous changes to kernel, 
compiler and libc. From an implementation point of view, a plan that 
requires all of that effort to happen simultaneously could be 
impracticable.

Better perhaps to add stuff to the existing ABI/API where possible. A new 
ABI could then come about as a consequence of removal of baggage and 
optimisation (presuming a performance increase to justify it).

> 
> >get/set_thread_area to a VDSO (as well as the atomic ops). As I 
> >understand it, this need not break the ABI and should be faster than 
> >the TLS system calls.
> 
> It will not break the ABI, but how'd it work?
> 
> - One kernel/user shared, readonly, page global (for time, atomic)
> - One kernel/user shared page per thread (instead of process), for TLS 
>   (and possibly random)?

Whatever is easiest to cut and paste from some other architecture, I guess 
(notwithstanding issues like TLB limitations and the capabilities of the 
two kinds of MMU that we support...)

Hopefully someone more knowledgeable can answer that question.

Finn