I've noticed that we've regressed on a pthread test "tst-attr1" and it
seems to complain that our thread variables are stored outside the stack
that the thred "thinks" is it's stack.

The following code is a simplified case of tst-attr1.c in the glibc
testsuite. I would recommend that you look at the original code too.

The question I have is... how is this supposed to work? If anyone is
more cluefull than me on this I would appreciate a pointer in the right
direction :)

===
./test-attr
In child
&a=0xfaf00ac8, stackaddr=0x40046e60, stacksize=0xbffb91a0
./test-attr: pthread_attr_getstack returned range does not cover main's stack
In parent
&a=0xfaf00ac8, stackaddr=0x40046e60, stacksize=0xbffb91a0
./test-attr: pthread_attr_getstack returned range does not cover main's stack
===

The variable is definately on the process stack. The thread's stack 
address seems to be inside the libraries 'writable' space and the stack 
size is wrong (or uninitialized). Perhaps I should just be looking for 
arch-dependant init code that we might be missing.

=== tst-attr1 from glibc ===
tst-attr1: pthread_attr_getstack returned range does not cover main's stack
thread stack 0x40245000-0x40a44000 (0x7ff000)
thread guardsize 4096
thread stack 0x40a45000-0x40c44000 (0x1ff000)
thread guardsize 4096
thread stack 0x40245000-0x40444000 (0x1ff000)
thread guardsize 65536
===

Attached is the Makefile to build the simplified tst-attr1.c (requires
test-skeleton.c wrapper, included aswell) or rather test-attr.c

Input and thoughts appreciated. This failure in glibc is rather
orthogonal to the release of 2.3.2, I'm still concentrating on the last
sysdep cancel failure (last bug to fix before a working release).

c.