regressions in gcc cause use of TLS emulation

[rmustacc]

Looking at a 64-bit gcc (in this case gcc47 in a multiarch 14.4 image), it appears to not have tls support enabled and is instead emulated through libgcc. Consider the following program:

#include <stdio.h>

int __thread hello;

int
main(void)
{
        printf("%d\n", hello);
        return (0);
}

When compiled in multiarch as 64-bit, we'll find that it's not using the normal AMD64 TLS translations and instead using libgcc. eg.:

[root@1d3594c1-2477-421c-b595-124f39f6d505 ~]# gcc -m64 tmp.c 
[root@1d3594c1-2477-421c-b595-124f39f6d505 ~]# /usr/bin/nm a.out | grep __emutls
[45]    |             4200640|                 527|FUNC |LOCL |2    |14     |__emutls_get_address
[44]    |             4201168|                  54|FUNC |LOCL |2    |14     |__emutls_register_common
[65]    |             4267936|                  32|OBJT |LOCL |0    |21     |__emutls_v.hello

If I look at the stock illumos gcc, it doesn't do anything like this and seems to use the native TLS translations for both 32-bit and 64-bit. Looking at multiarch 13.3 gcc47, it looks like it's properly using native tls and not being emulated. So it appears something has regressed here.

[rmustacc]

Actually, it looks like I mixed up where this seems to be broken. In 2014Q4 the 64-bit images have this regardless; however, the multiarch image doesn't seem to have it for either 32-bit or 64-bit.

[jperkin]

Whilst looking at a separate GCC issue I decided to compare this with various images.

Version	Image/-mXX	Contains __emutls?
13.3	base -m32	No
13.3	base -m64	No
13.3	base64 -m32	Yes
13.3	base64 -m64	Yes
13.3	multiarch -m32	No
13.3	multiarch -m64	No
14.2	base64 -m32	Yes
14.2	base64 -m64	Yes
14.3	base -m32	No
14.3	base -m64	No
14.3	base64 -m32	Yes
14.3	base64 -m64	Yes
14.3	multiarch -m32	No
14.3	multiarch -m64	No
14.4	minimal-64 -m32	Yes
14.4	minimal-64 -m64	Yes
14.4	minimal-multiarch -m32	No
14.4	minimal-multiarch -m64	No
15.1	minimal-32 -m32	No
15.1	minimal-32 -m64	No
15.1	minimal-64 -m32	Yes
15.1	minimal-64 -m64	Yes

Seems to be consistently limited to 64-bit builds, regardless of image version or platform. Will dig in deeper..

[jperkin]

If I'm reading the code correctly this appears to be a self-fulfilling prophecy. The test for whether to enable emutls is predicated on whether the bootstrap compiler uses it or not.

    gcc_cv_use_emutls=no
    echo '__thread int a; int b; int main() { return a = b; }' > conftest.c
    if { ac_try='${CC-cc} -Werror -S -o conftest.s conftest.c 1>&5'
  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
  (eval $ac_try) 2>&5
  ac_status=$?
  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
  test $ac_status = 0; }; }; then
      if grep __emutls_get_address conftest.s > /dev/null; then
        gcc_cv_use_emutls=yes
      fi
    fi
    rm -f conftest.*

I am building a 64-bit native GCC with an explicit gcc_cv_use_emutls=no and if that works ok then will integrate the change for 2015Q2.

Which Solaris release integrated TLS so that I can correctly configure this in pkgsrc?

[rmustacc]

It looks like it was present in Solaris 8 and 9; however, it required the use of the alternate threading libraries. At least, that's what I got from Solaris Internals. Maybe @richlowe knows more.

[jperkin]

That didn't help. Digging further, the failure is earlier when first checking for TLS support. It seems GNU as(1) doesn't work correctly in 64-bit mode:

• 32-bit config.log

configure:23666: checking assembler for thread-local storage support
configure:23679: /opt/local/bin/gas   --fatal-warnings -o conftest.o conftest.s >&5
configure:23682: $? = 0
configure:23693: result: yes

• 64-bit config.log

configure:23666: checking assembler for thread-local storage support
configure:23679: /opt/local/bin/gas   --fatal-warnings -o conftest.o conftest.s >&5
conftest.s: Assembler messages:
conftest.s:7: Error: @TLSLDM reloc is not supported with 64-bit output format
conftest.s:7: Error: junk `@tlsldm' after expression
conftest.s:8: Error: relocated field and relocation type differ in signedness
conftest.s:9: Error: relocated field and relocation type differ in signedness
conftest.s:10: Error: relocated field and relocation type differ in signedness
conftest.s:11: Error: @GOTNTPOFF reloc is not supported with 64-bit output format
conftest.s:11: Error: junk `@gotntpoff' after expression
conftest.s:12: Error: @INDNTPOFF reloc is not supported with 64-bit output format
conftest.s:12: Error: junk `@indntpoff' after expression
conftest.s:13: Error: relocated field and relocation type differ in signedness
conftest.s:14: Error: relocated field and relocation type differ in signedness
conftest.s:15: Error: @NTPOFF reloc is not supported with 64-bit output format
conftest.s:15: Error: junk `@ntpoff' after expression
configure:23682: $? = 1
configure: failed program was

        .section ".tdata","awT",@progbits
foo:    .long   25
        .text
        movl    %gs:0, %eax
        leal    foo@tlsgd(,%ebx,1), %eax
        leal    foo@tlsldm(%ebx), %eax
        leal    foo@dtpoff(%eax), %edx
        movl    foo@gottpoff(%ebx), %eax
        subl    foo@gottpoff(%ebx), %eax
        addl    foo@gotntpoff(%ebx), %eax
        movl    foo@indntpoff, %eax
        movl    $foo@tpoff, %eax
        subl    $foo@tpoff, %eax
        leal    foo@ntpoff(%ecx), %eax
configure:23693: result: no

Will switch to looking at binutils to see if we can support this 64-bit mode.

[jperkin]

The failure here (and I should have noticed before looking into binutils) is that the GCC test for GNU as(1) assumes that it will always operate in 32-bit mode by default, and only has a single 32-bit assembly test as shown above which is used for both 32-bit and 64-bit targets:

https://github.com/gcc-mirror/gcc/blob/gcc-4_7_4-release/gcc/configure.ac#L2900..#L2944

Our 64-bit builds use a 64-bit native binutils, hence the failure when trying to assemble. This has since been fixed upstream, and in GCC 5.1 uses specific assembly for the target, as well as ensuring gas(1) is called with the correct flags:

https://github.com/gcc-mirror/gcc/blob/gcc-5_1_0-release/gcc/configure.ac#L3069..#L3103

For our GCC 4.7 builds we will work around this for now with a simple patch to force gas(1) to use the -32 flag:

@@ -23374,7 +23374,7 @@ $as_echo "#define TLS_SECTION_ASM_FLAG '
        .section ".tdata","awT",@progbits'
       tls_first_major=2
       tls_first_minor=14
-      tls_as_opt="--fatal-warnings"
+      tls_as_opt="-32 --fatal-warnings"
     fi
     conftest_s="$conftest_s
 foo:   .long   25

and this will be integrated for our 2015Q2 builds. Testing this I observe the correct behaviour with the new build:

$ echo '__thread int a; int b; int main() { return a = b; }' >conftest.c

# 64-bit build without patch
$ /opt/tools/gcc47/bin/gcc -S -o conftest-old.s conftest.c

# 64-bit build with patch
$ /opt/local/gcc47/bin/gcc -S -o conftest-new.s conftest.c

$ ls -l conftest-{old,new}.s
-rw-r--r--   1 root     root         977 Jun 25 12:11 conftest-new.s
-rw-r--r--   1 root     root        1143 Jun 25 12:11 conftest-old.s

$ grep emutls conftest-{old,new}.s
conftest-old.s: movl    $__emutls_v.a, %edi
conftest-old.s: call    __emutls_get_address
conftest-old.s: .globl  __emutls_v.a
conftest-old.s: .type   __emutls_v.a, @object
conftest-old.s: .size   __emutls_v.a, 32
conftest-old.s:__emutls_v.a: