TLS support on NetBSD

[Ludovic Courtès-3]

Hi Greg,

NetBSD builds have been failing since the introduction of TLS support
(http://autobuild.josefsson.org/guile/log-200910220603170256000.txt):

  gcc -I/usr/pkg/include -I/usr/y0/include -Wall -Wmissing-prototypes -Werror -fvisibility=hidden -I/usr/pkg/include -g -O2 -I/usr/pkg/include -I/usr/y0/include -o .libs/guile guile-guile.o  -L/usr/pkg/lib -L/usr/y0/lib ./.libs/libguile.so /usr/pkg/lib/libintl.so -lc /usr/pkg/lib/libgmp.so /usr/pkg/lib/libgc.so -lpthread -lrt /usr/y0/lib/libunistring.so -lcrypt -lm /usr/pkg/lib/libltdl.so  -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/pkg/lib -Wl,--rpath -Wl,/usr/y0/lib
  ./.libs/libguile.so: warning: warning: tmpnam() possibly used unsafely, use mkstemp() or mkdtemp()
  ./.libs/libguile.so: undefined reference to `__tls_get_addr'

This looks as though TLS was not actually implemented in NetBSD’s libc.
Do you have any info on this?

Besides, I was hoping that
http://git.savannah.gnu.org/cgit/guile.git/commit/?id=96e15df109ccfdcc2f6b2cffc0b64a083f000903
would fix NetBSD builds, but apparently that’s not enough.  Any
suggestion to fix it?

Thanks,
Ludo’.

[Greg Troxel]

Thanks - I think there is actually no tls support yet.

I will take a look at the autoconf issue when I have time - but I'm very
busy at work this week.

[Ken Raeburn-2]

On Oct 23, 2009, at 19:40, Greg Troxel wrote:
> Thanks - I think there is actually no tls support yet.
>
> I will take a look at the autoconf issue when I have time - but I'm  
> very
> busy at work this week.

I just took a little bit of a look... on my NetBSD 5.0.1 x86 system,  
the __thread support simply uses the %gs segment register, but the  
kernel or library or whatever doesn't seem to have set it up  
properly.  So it compiles and links just fine for me, but crashes when  
running.

I think the autoconf test is thus going to have to run a test program  
to see if __thread is supported, which means it won't be friendly to  
cross-compilation setups.  (I still don't have all the dependencies  
built for NetBSD, so no working patch.)  Or, we could hard-code  
knowledge about systems where compiling and linking work but execution  
fails; that's generally frowned upon....

Ken

[Ludovic Courtès-3]

Hey,

Ken Raeburn <raeburn@...> writes:

> I just took a little bit of a look... on my NetBSD 5.0.1 x86 system,
> the __thread support simply uses the %gs segment register,

That’s weird because it should only do such things with the
‘initial-exec’ or ‘local-exec’ thread models; otherwise, it relies on
support from the C library at run-time, something called
‘__tls_get addr ()’ in glibc.

> but the kernel or library or whatever doesn't seem to have set it up
> properly.  So it compiles and links just fine for me, but crashes when
> running.

Hmm, not good.

> I think the autoconf test is thus going to have to run a test program
> to see if __thread is supported, which means it won't be friendly to
> cross-compilation setups.  (I still don't have all the dependencies
> built for NetBSD, so no working patch.)  Or, we could hard-code
> knowledge about systems where compiling and linking work but execution
> fails; that's generally frowned upon....

Yeah, that doesn’t sound very good.

Thanks,
Ludo’.

[Ken Raeburn-2]

On Oct 29, 2009, at 18:24, Ludovic Courtès wrote:
>> I just took a little bit of a look... on my NetBSD 5.0.1 x86 system,
>> the __thread support simply uses the %gs segment register,
>
> That’s weird because it should only do such things with the
> ‘initial-exec’ or ‘local-exec’ thread models; otherwise, it relies on
> support from the C library at run-time, something called
> ‘__tls_get addr ()’ in glibc.

I was compiling an application, not a library file; I'm not sure if  
that makes a difference.  It might, now that I think about it.  
(...type type type...)  Ah, yes.  If I add -fPIC, it generates a call  
to __tls_get_addr.  But the test code in the configure script is  
compiled as a program, not as a library module, so it wouldn't get the  
link error.

Looks like the NetBSD folks have been seeing this problem for at least  
2.5 years, too, since before the last major release, and apparently  
haven't addressed it: http://mail-index.netbsd.org/tech-toolchain/2007/04/25/0000.html 
  .

Ken