This is an archive of the discontinued LLVM Phabricator instance.

[libcxx][CMake] Add an option to include -lgcc_s in the linker script
Needs RevisionPublic

Authored by tstellar on Apr 16 2019, 1:20 PM.

Details

Reviewers
mstorsjo
ldionne
phosek
EricWF
Group Reviewers
Restricted Project
Summary

This adds the LIBCXXABI_USE_LIBGCC_UNWINDER cmake option, which is the
libgcc version of LIBCXXABI_USE_LLVM_UNWINDER. When enabled, it will
add -lgcc_s to the libc++.so linker script, so that users will not
need to explicitly link to an unwind library when linking with libc++.so.

Event Timeline

tstellar created this revision.Apr 16 2019, 1:20 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 16 2019, 1:20 PM
phosek added inline comments.Apr 16 2019, 4:15 PM
libcxx/test/lit.site.cfg.in
30

No need to wrap the value in " to make it a string since it's already Pythonized as bool.

libcxx/utils/libcxx/test/target_info.py
263

s/eanbled/enabled/

I don't think this is correct.

The compiler should be linking gcc unwind for us, and there should be no need for users to link it themselves.

We only do it in the test suite because we can't drop the C++ standard library without dropping the rest of the link line (At least before -nostdlibc++ existed).

Also I don't think a libc++ build is tied to any one particular unwind library?

libcxx/utils/libcxx/test/target_info.py
253

We really should be replacing this whole thing with -nostdlib++ (And I would if GCC supported it).

I don't think this is correct.

The compiler should be linking gcc unwind for us, and there should be no need for users to link it themselves.

Ok, I wasn't sure the correct place to fix this. clang does not currently add the gcc unwind library. I thought clang was assuming that the unwind library would always be specified in the linker script since this is what happens with the LLVM unwinder.

Here is an example to reproduce the problem in clang:

cat << EOF | ./bin/clang++ -x c++ -fuse-ld=lld -rtlib=compiler-rt -stdlib=libc++ -

#include <iostream>
int main(int argc, char **argv) {
  std::cout << "Hello World\n";
  return 0;
}
EOF

ld.lld: error: undefined symbol: _Unwind_Resume
>>> referenced by -
>>>               /tmp/--697774.o:(std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::__put_character_sequence<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*, unsigned long))

ld.lld: error: undefined symbol: _Unwind_Resume
>>> referenced by -
>>>               /tmp/--697774.o:(std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> > std::__1::__pad_and_output<char, std::__1::char_traits<char> >(std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> >, char const*, char const*, char const*, std::__1::ios_base&, char))
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)

We only do it in the test suite because we can't drop the C++ standard library without dropping the rest of the link line (At least before -nostdlibc++ existed).

Also I don't think a libc++ build is tied to any one particular unwind library?

It can be when the option LIBCXXABI_USE_LLVM_UNWINDER=ON is used, at least on Linux.

ldionne requested changes to this revision.Nov 2 2020, 2:58 PM
ldionne added a reviewer: Restricted Project.

I agree with Eric this seems to be the wrong place to do this. Is this still a problem we want to solve? If not, let's abandon this to clear up the review queue.

This revision now requires changes to proceed.Nov 2 2020, 2:58 PM