nptl: or1k, kvx: align the TLS block to struct pthread
tst-tls3 wants the initial thread's descriptor 16-byte aligned and got 8 on
or1k, so it aborted before doing anything else.
Both architectures are TLS_DTV_AT_TP with TLS_PRE_TCB_SIZE = sizeof (struct
pthread): the descriptor sits at the start of the allocated block and
THREAD_SELF hands it out. The block's alignment comes from TLS_TCB_ALIGN in
the dynamic case, through _dl_tls_static_align, and from TLS_INIT_TCB_ALIGN in
the static one, which __libc_setup_tls() takes as its max_align. These two
architectures are the only ones deriving either from tcbhead_t -- on or1k that
is a single pointer, so the alignment was 4 and the descriptor landed wherever
the allocator happened to put it. The other nineteen use
__alignof__ (struct pthread), which is what the object at that address needs.
Measured on or1k under qemu-or1k, printing pthread_self():
dynamic 0x30810818 & 15 = 8 -> 0x30810820 & 15 = 0
static 0x0001245c & 15 = 12 -> 0x00012460 & 15 = 0
The static figure needed a separate build with HAVE_SHARED off, since
libc-tls.c is only compiled for binaries without a loader.
Full suite on or1k/6.1.53: 769 passed, 0 failed, 7 skipped -- was 768/1/7.
kvx gets the same change on the same reasoning, but is not measured: the probe
needs a libpthread-internal build and the toolchain's bundled sysroot is
threadless, so __alignof__ (struct pthread) could not be read out locally. The
change can only raise the alignment, never lower it, and kvx runs tst-tls3
under qemu, so a regression would show.
Signed-off-by: Ramin Moussavi <lordrasmus@gmail.com>
ramin