Giters

flame / blis

BLAS-like Library Instantiation Software Framework

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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

taber6996 opened this issue · comments

commented

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 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.

this is the configure command I use:
./configure --disable-shared --disable-system CC=clang CFLAGS="-D__linux__" riscv

As of the code of the microkernel, I didn't really did anything yet, I just copied the generic and created the new configuration, family, etc.
CMISCFLAGS := -dynamic --target=riscv64 -march=rv64g -isystem /scratch/aletab01/riscv/riscv64-unknown-elf/include
This are the compiling flags that I used, but for the moment compiling isn't much of an issue.

EDIT: I forgot to mention that what I'm trying to build right now is the testsuite. I can generate the resulting blis static library, but I get all this problems when I try to build the testsuite to check everything works fine.

commented

Hi @taber6996 and welcome to the BLIS community.

Quick response:
Try configure --disable-tls --disable-system to disable Thread-local storage (TLS) in BLIS. But be aware of possible data race. If you only consider single-threaded code for the moment, add --disable-threading as well.

Long response:
Details can be found in below:

I was in a very similar situation as yours several years ago when I tried to port and optimize BLIS on a novel embedded architecture. I can imagine all the problems the developer can encounter (toolchain, compilers, memory/stack/code-size footprints etc.).

There were several discussions in the past around "How to port BLIS on a bare metal system with no (poor) threading support". If you are interested I can find them back.

I believe that there will be more and more people in the future coming up wanting to port BLIS on their custom/exotic/bare/unconventional architectures & ISA. If you find yourself in such tasks, feel free to ask and share your experiences. Maybe we can contribute something to BLIS if we are numerous enough.

commented

We had the same issue when adding our RISC-V target #737 . @fgvanzee added #735 to help us move past this. In personal conversation with @kito-cheng I came to believe it is a toolchain bug related to emulated a.k.a. "soft" TLS. If so, should be reported elsewhere.

commented

Thanks to you both!! SO nice seeing that the community is so active! I would love to read those conversations if you have them at hand. Also I was developing over the latest release version of BLIS (0.9.0) but in that version the"--disable-tls" option didn't exist yet so I will try to update to a newer version and see if it works. I will post my results!

commented

@taber6996 We're in the midst of some longer-term changes to the software architecture of BLIS, and I'd like that to settle down before the next version release, which is why it's been so long since the last official version. That said, I and others do try to keep the master branch as functional as possible, so it should suit your purposes for now.

Let us know if you have any further questions!

commented

@taber6996 Some readings: