Mixing objects with `thread_local` in C++ and `_Thread_local` in C

[simark]

Bugzilla Link	51814
Version	12.0
OS	Linux
CC	@DougGregor,@zygoloid

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?

[AaronBallman]

CC @hubert-reinterpretcast -- IIRC, we found that thread_local in C++ and _Thread_local in C are functionally different, would that account for this kind of behavior?

[hubert-reinterpretcast]

CC @hubert-reinterpretcast -- IIRC, we found that thread_local in C++ and _Thread_local in C are functionally different, would that account for this kind of behavior?

Hi Aaron,

While this code does represent the problem discussed in https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2478r0.pdf, on Linux, the problem is supposed to be avoidable (and it is normally avoided because the reference to the initialization function is declared weak).

The problem in this case appears to be the dso_local in:

declare extern_weak dso_local hidden void @_ZTH18logger_thread_name() #2

-- HT

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: None (70e8c5c0-afb3-4429-baaf-906675eb77bb)

| | | | --- | --- | | Bugzilla Link | [51814](https://llvm.org/bz51814) | | Version | 12.0 | | OS | Linux | | CC | @DougGregor,@zygoloid |

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?