Segfault when execution for tls test

[kito-cheng]

Arch: RV32I, RV32G
Option: -pthread -O1

How to reproduce:

$ riscv32-unknown-linux-gnu-gcc tls-test.c  -pthread -O1
$ qemu-riscv32 -L `riscv32-unknown-linux-gnu-gcc --print-sysroot` a.out
Segmentation fault (core dumped)

Code for tls-test.c:

#include <pthread.h>
extern int printf (char *,...);
__thread int a = 5; 
int *volatile a_in_other_thread = (int *) 12345;

static void *
thread_func (void *arg)
{
  a_in_other_thread = &a;
  a+=5;
  *((int *) arg) = a;
  return (void *)0;
}

int
main ()
{
  pthread_t thread;
  void *thread_retval;

  int *volatile a_in_main_thread;
  int *volatile again ;
  int thr_a;

  a_in_main_thread = &a;

  if (pthread_create (&thread, (pthread_attr_t *)0, thread_func, &thr_a))
    return 0;

  if (pthread_join (thread, &thread_retval))
    return 0;

  again = &a;
  if (again != a_in_main_thread)
    {
      printf ("FAIL: main thread addy changed from 0x%0x to 0x%0x\n", 
                a_in_other_thread, again);
      return 1;
    }

  if (a != 5 || thr_a != 10 || (a_in_other_thread == a_in_main_thread))
    {
      printf ("FAIL: a= %d, thr_a = %d Addr = 0x%0x\n", 
                a, thr_a, a_in_other_thread);
      return 1;
    }
  return 0;
}

[aswaterman]

Looks like qemu is segfaulting, not the TLS test.

@sagark can you look into this? I put the stuff you need to replicate the failure in /scratch/waterman/toolchain32/ on a5: Just hop in that directory and run

qemu-riscv32 -L /scratch/waterman/toolchain32/sysroot ./a.out

[kito-cheng]

I guess those test case is same as this case:

g++.dg/tls/thread_local3.C
g++.dg/tls/thread_local3g.C
g++.dg/tls/thread_local4.C
g++.dg/tls/thread_local4g.C
g++.dg/tls/thread_local5.C
g++.dg/tls/thread_local5g.C

[aswaterman]

It looks like the -pthread option alone is enough to trigger this (the code in main() doesn't matter).

[aswaterman]

I think this is a duplicate of riscv-collab/riscv-gnu-toolchain#192 but I am working on it.