undefined reference to __atomic_* for simple c++ program

[kito-cheng]

Current toolchain will generate lots of undefined reference for simple c++ program, and it's seem cause by this patch riscvarchive/riscv-gcc@48f0f64 , it's made libgcc add dependency to libatomic.

For example:

#include <iostream>

int main(){
  std::cout << "aloha~\n";
  return 0;
}

$ riscv64-unknown-linux-gnu-g++ hello.cpp 
/local/kito/riscv-gnu-toolchain/newlib-toolchain/lib/gcc/riscv64-unknown-linux-gnu/6.1.0/../../../../riscv64-unknown-linux-gnu/lib/../lib/libgcc_s.so: undefined reference to `__atomic_compare_exchange_2'
/local/kito/riscv-gnu-toolchain/newlib-toolchain/lib/gcc/riscv64-unknown-linux-gnu/6.1.0/../../../../riscv64-unknown-linux-gnu/lib/../lib/libgcc_s.so: undefined reference to `__atomic_fetch_nand_1'
/local/kito/riscv-gnu-toolchain/newlib-toolchain/lib/gcc/riscv64-unknown-linux-gnu/6.1.0/../../../../riscv64-unknown-linux-gnu/lib/../lib/libgcc_s.so: undefined reference to `__atomic_fetch_add_2'
/local/kito/riscv-gnu-toolchain/newlib-toolchain/lib/gcc/riscv64-unknown-linux-gnu/6.1.0/../../../../riscv64-unknown-linux-gnu/lib/../lib/libgcc_s.so: undefined reference to `__atomic_fetch_xor_1'
/local/kito/riscv-gnu-toolchain/newlib-toolchain/lib/gcc/riscv64-unknown-linux-gnu/6.1.0/../../../../riscv64-unknown-linux-gnu/lib/../lib/libgcc_s.so: undefined reference to `__atomic_fetch_or_2'
/local/kito/riscv-gnu-toolchain/newlib-toolchain/lib/gcc/riscv64-unknown-linux-gnu/6.1.0/../../../../riscv64-unknown-linux-gnu/lib/../lib/libgcc_s.so: undefined reference to `__atomic_fetch_and_1'
/local/kito/riscv-gnu-toolchain/newlib-toolchain/lib/gcc/riscv64-unknown-linux-gnu/6.1.0/../../../../riscv64-unknown-linux-gnu/lib/../lib/libgcc_s.so: undefined reference to `__atomic_compare_exchange_1'
/local/kito/riscv-gnu-toolchain/newlib-toolchain/lib/gcc/riscv64-unknown-linux-gnu/6.1.0/../../../../riscv64-unknown-linux-gnu/lib/../lib/libgcc_s.so: undefined reference to `__atomic_fetch_sub_1'
/local/kito/riscv-gnu-toolchain/newlib-toolchain/lib/gcc/riscv64-unknown-linux-gnu/6.1.0/../../../../riscv64-unknown-linux-gnu/lib/../lib/libgcc_s.so: undefined reference to `__atomic_fetch_and_2'
/local/kito/riscv-gnu-toolchain/newlib-toolchain/lib/gcc/riscv64-unknown-linux-gnu/6.1.0/../../../../riscv64-unknown-linux-gnu/lib/../lib/libgcc_s.so: undefined reference to `__atomic_fetch_sub_2'
/local/kito/riscv-gnu-toolchain/newlib-toolchain/lib/gcc/riscv64-unknown-linux-gnu/6.1.0/../../../../riscv64-unknown-linux-gnu/lib/../lib/libgcc_s.so: undefined reference to `__atomic_fetch_nand_2'
/local/kito/riscv-gnu-toolchain/newlib-toolchain/lib/gcc/riscv64-unknown-linux-gnu/6.1.0/../../../../riscv64-unknown-linux-gnu/lib/../lib/libgcc_s.so: undefined reference to `__atomic_fetch_add_1'
/local/kito/riscv-gnu-toolchain/newlib-toolchain/lib/gcc/riscv64-unknown-linux-gnu/6.1.0/../../../../riscv64-unknown-linux-gnu/lib/../lib/libgcc_s.so: undefined reference to `__atomic_fetch_xor_2'
/local/kito/riscv-gnu-toolchain/newlib-toolchain/lib/gcc/riscv64-unknown-linux-gnu/6.1.0/../../../../riscv64-unknown-linux-gnu/lib/../lib/libgcc_s.so: undefined reference to `__atomic_fetch_or_1'
collect2: error: ld returned 1 exit status

[aswaterman]

oops, i'm on it

[aswaterman]

Since these are legacy, it kind of seems like the right thing to do is to link libatomic.a into libgcc_s.so, until they are finally removed... is that possible?

[aswaterman]

Nevermind. I've fixed it directly: riscvarchive/riscv-gcc@62da3c0

@kito-cheng @palmer-dabbelt can you give a careful code review?

[kito-cheng]

Look good to me, but I am curious why change to unsigned type?

I seem signed and unsigned are both used in other target.
nios2, sh, m68k : unsigned
pa, arm : signed

[aswaterman]

For RV, at least, gcc seems to assume the return type is unsigned. If you
use these on a signed type, gcc explicity sign-extends the return value,
but for unsigned types, it does nothing.

On Monday, October 3, 2016, Kito Cheng notifications@github.com wrote:

Look good to me, but I am curious why change to unsigned type?

I seem signed and unsigned are both used in other target.
nios2, sh, m68k : unsigned
pa, arm : signed

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#183 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-7wqzRNJg4IR5OjanzrzvhXXH-aUTgks5qwLrNgaJpZM4KMMaf
.

[davidlt]

We were hitting the same issue (in various packages) while building Fedora packages.

[sorear]

@davidlt (we have already settled this on IRC, but I'm reposting for the benefit of anyone who stumbles on the ticket) programs which use C11 or C++11 atomics, like #include <atomic>, generally must link against -latomic. I consider this a gcc bug, but it's an upstream gcc bug that affects all architectures.

The effect is relatively small for x86 which has byte-sized atomic instructions; other arches like ARM see a greater effect (see for instance the Android NDK documentation which encourages -latomic whenever yu #include <atomic>).