I get "undefined reference to `__tls_get_addr'" when linking using the gnu toolchain

[taber6996]

Hi, I will explain my project to give a little bit of context on the issue.
Currently I'm working on developing a new microkernel for the BLIS api (https://github.com/flame/blis) that gives support to RISC-V architectures. More precisely I'm trying to make BLIS work on a core based on CVA-6(https://github.com/openhwgroup/cva6) that uses posit format instead of floating-point format(https://github.com/artecs-group/PERCIVAL), which I believe is single-threaded. The thing is, to make all this mix work I'm compiling BLIS using a modified version of LLVM that I found on this repo, https://github.com/artecs-group/llvm-xposit, and linking using this toolchain. The thing is that following in the instructions found in the xposit repo it states that i need to install the riscv gnu-toolchain following the instructions of newlib/multilib, doing this the directory /sysroot isn't created on the directory where I install the toolchain. So when I try to compile+link the BLIS library compilations seems to work ok but when linking I get the following error "Linking test_libblis.x against 'lib/riscv/libblis.a -lm '
.../riscv/lib/gcc/riscv64-unknown-elf/12.2.0/../../../../riscv64-unknown-elf/bin/ld: lib/riscv/libblis.a(bli_error.o): in function .LBB2_1': bli_error.c:(.text+0xf0): undefined reference to __tls_get_addr'". I asked the all knowing prophet (chatGPT) and it suggested that the problem came from libc library, and after some searching it appers that it didn't come with the version I installed or I don't seem to find it, Should a version of libc come with other type of installations? Honestly I don't really understand the differences.
On a side note, I also had problems with librt library which I also didn't find on the newlib/multilib configured installation.
So my issue would be how should I configure the toolchain so I can access to it's versions of libc and librt, would also prefer for them to be static versions since the library I want to produce is also static.

[TommyMurphyTM1234]

See this closed issue (always search open and closed issues before logging a new issue):

• Regression suite: undefined reference to `__tls_get_addr' #752 (comment)

I presume that this comment from @jim-wilson still applies:

I would not expect the TLS (Thread Local Storage) tests to work for an embedded elf target. Our newlib port does not have TLS support.

in which case the issue should be logged and dealt with upstream in the Newlib project.

• https://sourceware.org/newlib/

Regarding librt I'm not sure that Newlib supports that but, again, you'll get better support on Newlib specific questions upstream.

On the other hand, maybe you should be using the RISC-V Linux toolchain (and, thus, GLIBC etc.) rather that the bare-metal embedded Newlib toolchain for your purposes?

[taber6996]

Hi, thanks for your answer!! I try to take this issue to the Newlib project thanks for the suggestion! Regarding the other point, the issue is that I'm gonna load an image of the generated BLIS library onto an FPGA programmed with the PERCIVAL core, that's the reason why I need the bare-metal toolchain.

[TommyMurphyTM1234]

Regarding the other point, the issue is that I'm gonna load an image of the generated BLIS library onto an FPGA programmed with the PERCIVAL core, that's the reason why I need the bare-metal toolchain.

Ok, but if you have a dependency on librt which seems to be a POSIX subsystem

• https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/app-librt.html

then I'm not sure that you're going to find such support in a Newlib bare-metal toolchain?

BTW, an alternative to Newlib with TLS support might be Picolibc:

• https://github.com/picolibc/picolibc
• https://github.com/picolibc/picolibc/blob/main/doc/tls.md

But, unfortunately the PR to add support to riscv-gnu-toolchain seems to have stalled:

• Picolibc support #1119

[taber6996]

Well the dependency comes from the testsuite of BLIS, since it gives information about runtimes of the different operations. This testsuite is pretty convenient to my project since it would help me get metrics of the performance on the core and get conclusions on viability of other hardware implementations that give support to the posit format.
I am not completely closed to the idea of switching to other more convenient toolchain, but this is the one recommended in one of the repositories that I'm using (https://github.com/artecs-group/llvm-xposit). Do you know if there's support in this toolchain for operations to extract metrics like runtime, gflops, etc?

[TommyMurphyTM1234]

Do you know if there's support in this toolchain for operations to extract metrics like runtime, gflops, etc?

Which toolchain are you referring to here?

[taber6996]

Do you know if there's support in this toolchain for operations to extract metrics like runtime, gflops, etc?

Which toolchain are you referring to here?

This riscv-gnu-toolchain. I must add that I'm pretty new to working with bare-metal systems so my knowledge is limited. Also i read the links regarding newlib and librt, turns out that the librt library is maintained to provide backward compatibility for both runtime and compilation environments and all it's functionality is included in libc. But again libc seems to not be supported by the Newlib project, in the readme the configuration option of Newlib is referenced with a Linux multilib option, would this Linux multilib option give support to libc? Sorry for all this questions but I can't find much documentation about this topics and also in the readme/wiki in this repository there isn't much information about support to different libraries.
I think I might have a misconception, since I thought this toolchain allowed me to use c libraries in a RISC-V environment, and this also included Linux libraries.

[TommyMurphyTM1234]

This riscv-gnu-toolchain.

The only thing that I can think of is gprof but getting even that running on a bare-metal target takes some effort and I'm not sure that it would provide the sort of data that you're looking for. For example (Arm Cortex-M related but the general principles are the same for any embedded target):

• https://mcuoneclipse.com/2015/08/23/tutorial-using-gnu-profiling-gprof-with-arm-cortex-m/

I must add that I'm pretty new to working with bare-metal systems so my knowledge is limited. Also i read the links regarding newlib and librt, turns out that the librt library is maintained to provide backward compatibility for both runtime and compilation environments and all it's functionality is included in libc. But again libc seems to not be supported by the Newlib project, in the readme the configuration option of Newlib is referenced with a Linux multilib option, would this Linux multilib option give support to libc?

Sorry, your comments/queries are confusing and I'm not really sure what you're asking about here. Newlib basically has nothing to do with Linux - it's a bare bones C standard library (libc, libm etc.) for (usually resource constrained) embedded targets that have no OS or maybe a lightweight [RT]OS as opposed to a fully fledged OS like Linux. If you have specific questions about Newlib and its capabilities then you'll get better support in the relevant Newlib forums.

But again libc seems to not be supported by the Newlib project, in the readme the configuration option of Newlib is referenced with a Linux multilib option, would this Linux multilib option give support to libc?

I don't know what you're referring to here. Newlib is a "libc" implementation - just a lightweight version for embedded targets. GLIBC is another and a common one used on Linux. musl is another Linux C standard library. I don't know what this means:

the configuration option of Newlib is referenced with a Linux multilib option

Ultimately though, I don't think that this issue identifies any specific problem with the riscv-gnu-toolchain and, as such, it is probably a candidate for closure.

[TommyMurphyTM1234]

Ultimately though, I don't think that this issue identifies any specific problem with the riscv-gnu-toolchain and, as such, it is probably a candidate for closure.

Closed.