Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libcxx tests fail when built with gcc (symbol visibility problem) std::__1::__vector_base_common<true>::__throw_length_error() const' #42485

Closed
smithp35 opened this issue Aug 28, 2019 · 8 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi.

Comments

@smithp35
Copy link
Collaborator

Bugzilla Link 43140
Resolution FIXED
Resolved on Aug 28, 2019 14:17
Version unspecified
OS Linux
CC @ldionne,@mclow
Fixed by commit(s) r370240

Extended Description

One of our libcxx buildbots http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv7-linux-noexceptions/builds/1102 is failing.

As a side effect of moving some buildbots around, this builder ended up building libcxx, libcxxabi and libunwind with GCC 7.4.0. With this configuration 437 tests fail due to link errors of the form:
more undefined references to `std::__1::__vector_base_common::__throw_length_error() const' follow

This is reproducible on x86_64 with or without -fno-exceptions and it looks like it is related to symbol visibility differences.

The bits of code where the problem are:
File vector:

template
class __vector_base_common
{
protected:
_LIBCPP_INLINE_VISIBILITY __vector_base_common() {}
_LIBCPP_NORETURN void __throw_length_error() const;
_LIBCPP_NORETURN void __throw_out_of_range() const;
};

template
void
__vector_base_common<__b>::__throw_length_error() const
{
_VSTD::__throw_length_error("vector");
}

_LIBCPP_EXTERN_TEMPLATE(class _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS __vector_base_common)

File stdexcept
_LIBCPP_NORETURN inline _LIBCPP_INLINE_VISIBILITY
void __throw_length_error(const char*__msg)
{
#ifndef _LIBCPP_NO_EXCEPTIONS
throw length_error(__msg);
#else
((void)__msg);
_VSTD::abort();
#endif
}

When compiled with clang:
00000000 w F .text._ZNKSt3__120__vector_base_commonILb1EE20__throw_length_errorEv 00000018 std::__1::__vector_base_common::__throw_length_error() const
00000000 w F .text._ZNSt3__120__throw_length_errorEPKc 00000010 .hidden std::__1::__throw_length_error(char const*)

When compiled with gcc:
00000000 w F .text._ZNKSt3__120__vector_base_commonILb1EE20__throw_length_errorEv 00000018 .hidden std::__1::__vector_base_common::__throw_length_error() const

Note that std::__1::__vector_base_common::__throw_length_error() const has hidden visibility when compiled with GCC. This is the root cause of the link errors.

This looks to be caused by the expansion of the macros in:
_LIBCPP_EXTERN_TEMPLATE(class _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS __vector_base_common)

With GCC this expands to:
extern template class __vector_base_common;

With clang this expands to:
extern template class attribute ((visibility("default"))) __vector_bas
e_common;

With the compilation options -fvisibility=hidden and -fvisibility-inlines-hidden the end result is hidden visibilty when compiled with GCC.

Depending on whether libc++ supports gcc, this is probably a bug.

@smithp35
Copy link
Collaborator Author

assigned to @ldionne

@smithp35
Copy link
Collaborator Author

@mclow
Copy link
Contributor

mclow commented Aug 28, 2019

This also looks like it is hitting ...

That's very odd. The declaration of __throw_length_error has not changed since 2016, and we've been running gcc bots since before that. I wonder what changed to make that not work.

@smithp35
Copy link
Collaborator Author

Looking at the bot history of libcxx-libcxxabi-x86_64-linux-ubuntu-gcc5-cxx11 (should have thought of that earlier) it looks like http://llvm.org/viewvc/llvm-project?revision=368703&view=revision is what triggered it. [libc++] Always build with -fvisibility=hidden

@ldionne
Copy link
Member

ldionne commented Aug 28, 2019

Yeah, this is most likely mine. I did test the change on Linux in a Docker image, but it looks like I didn't test on GCC in the Docker image. Looking into it.

@ldionne
Copy link
Member

ldionne commented Aug 28, 2019

Should be fixed by r370240, please confirm.

@smithp35
Copy link
Collaborator Author

The Arm builder hasn't finished yet, but the other gcc libcxx bots have and I've done a local build on an Arm machine and this error is now gone.

I'm still getting some failures, as are the bots, but they look to be separate from this one. Will be worth a look to see if there are other problems when compiling with gcc.

Finished GCC builders (28 Failures, down from over 400)
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc-tot-latest-std/builds/1348
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc5-cxx11/builds/373

Some of the errors are static asserts, but there are also a few undefined symbol link errors.

Arm v7 builder, currently testing, will be finished in a few hours:
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv7-linux-noexceptions/builds/1103/steps/test.libcxx/logs/stdio

@ldionne
Copy link
Member

ldionne commented Aug 28, 2019

Yes, I think my fix did solve the problem for __vector_base_common, but not for all link errors. I'm still working on fixing the rest of them.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi.
Projects
None yet
Development

No branches or pull requests

3 participants