Re: tough choice on thread pointer initialization issue

[Rich Felker <dalias@aerifal.cx>]

On Fri, Feb 10, 2012 at 11:40:02AM +0400, Solar Designer wrote:
> > [approaches 1 & 2]
> I think another con of the two approaches above is that they'll fail if
> a program sets up a signal handler in a way bypassing musl (and other
> prerequisites of the problem are met as well, as you described them).
> Indeed, this makes it even more of a special case, but it's still legal
> (or not? that's a musl policy thing I guess).

Well the only ways to install a signal handler short of making the
syscall yourself and bypassing libc is to call sigaction() or
signal(), so I don't think this is too much of an issue... At this
point all or at least most bets are off.

> Not a strong opinion, but how about:
> 
> approach 4: initialize the thread pointer register to zero at program
> startup.  Then before its use, just check it for non-zero instead of
> checking a global flag.  (I presume that you're doing the latter now,
> based on your description of the problem.)

Well this is definitely feasible but it makes more arch-specific code,
since examining the thread register needs asm. I suspect "mov %gs,%ax"
might be slow on some machines, too, since the segment registers
aren't intended to be read/written often. I just don't know enough to
know if it's a good approach; if you really think it's potentially the
best, perhaps you could provide more info.

As for approach #3, I've found that, at least on x86, it's possible to
setup an LDT entry for %gs for the main thread's thread pointer even
on ancient kernels, going all the way back to 1.2.x, using modify_ldt
syscall. This would just be a little bit of fallback code for when the
set_thread_area syscall fails with ENOSYS, and it would make it so
musl binaries using %gs-based thread pointer would work on any Linux,
not just 2.6+ (musl requires 2.6+ for thread support and lots of newer
features, but simple programs should run on old kernels). I'm not sure
to what extent the same would be possible on other archs. Anyway the
point is that we could mostly (possibly arch-dependent tho) avoid the
"con" of having to tip-toe around not using the thread pointer in code
that might be used in single-threaded apps if it's possible to setup
the thread pointer for at least the main thread even on old kernels.

Rich