Extended Description

Hi,

I'm not sure that this is really a bug, but if I could at least get an explanation of what is happening I'd be really happy. With clang 12, this fails to build:

$ cat tls.c

extern __attribute__((visibility("hidden"))) _Thread_local const char *logger_thread_name;

__attribute__((visibility("hidden"))) _Thread_local const char *logger_thread_name;

$ cat main.cpp

extern "C" {
  extern __attribute__((visibility("hidden")))
    // Works if you use _Thread_local
    // _Thread_local
    thread_local
    const char *logger_thread_name;
}

const char *func() {
    return logger_thread_name;
}

$ cat build.sh 
clang++ main.cpp -c -fPIC -DPIC
clang tls.c -c -fPIC -DPIC
clang++ main.o tls.o -shared
$ bash build.sh
/usr/bin/ld: main.o: relocation R_X86_64_PC32 against undefined hidden symbol `_ZTH18logger_thread_name' can not be used when making a shared object
/usr/bin/ld: final link failed: bad value
clang-12: error: linker command failed with exit code 1 (use -v to see invocation)

What we have here is:

• a C source file defining a TLS variable using _Thread_local, with the attribute visibility("hidden")
• a C++ source file using this TLS variable, the declaration it sees is in an extern "C", but uses thread_local, and also has the attribute visibility("hidden")
• both
• we compile both using -fPIC and link them into a shared library
• the linking fails because of an invalid relocation type

The link is successful is you either:

• change the declaration in the C++ file to use the C keyword _Thread_local instead
• change the declaration in the C++ file to remove the visibility("hidden") attribute

Is the code above doing things that we really shouldn't do? Regardless of that, is there some bug in clang, given that it produces a R_X86_64_PC32 relocation in a file built with -fPIC?