port-xen/44988: All programs linked against libpthread segfault under Xen 32 bits due to TLS

[jym%NetBSD.org@localhost]

>Number:         44988
>Category:       port-xen
>Synopsis:       All programs linked against libpthread segfault under Xen 32 
>bits due to TLS
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    port-xen-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon May 23 13:05:00 +0000 2011
>Originator:     Jean-Yves Migeon
>Release:        current (5.99.51)
>Organization:
>Environment:
NetBSD  5.99.51 NetBSD 5.99.51 (XEN3PAE_DOM0) #26: Mon May 23 14:11:55 CEST 
2011  jym@paris:/home/jym/cvs/obj/sys/arch/i386/compile/XEN3PAE_DOM0 i386
>Description:
Applicable to: i386 architecture, all Xen NetBSD kernels (dom0 and domU, PAE 
and !PAE)

Following rev. 1.77 of lib/libpthread/pthread_int.h, all programs linked with 
libpthread support will segfault, including xend/xebackendd, which definitely 
hamper dom0/domU correct functionality in NetBSD.

amd64 is not affected.

The issue is very likely due to the implementation of TLS (Thread Local 
Storage) recently added to libpthread. There have been numerous reports of 
breakage with TLS under Xen with glibc, which required its own libc for that 
for some time (yikes). I believe it has something to do with the way segments 
are used with TLS, but I am not familiar enough with the implementation to 
clearly identify the culprit.
>How-To-Repeat:
Boot a 32 bits dom0/domU kernel (from source after 2011-03-16), and try 
executing any program compiled against libpthread.
>Fix:
Not known, but there are helpful pointers in the Xen wiki:

http://wiki.xensource.com/xenwiki/XenSpecificGlibc

This may need some adaptation to fit the way we handle TLS in NetBSD, though.