This is an archive of the discontinued LLVM Phabricator instance.

[libcxx] [test] Link against msvcprt as C++ ABI library in tests
ClosedPublic

Authored by mstorsjo on Mar 24 2021, 7:06 AM.

Details

Summary

This library provides some parts of the C++ ABI bits needed when running on top of vcruntime.

This matches what we link the library itself against (set in CMakeLists.txt). When testing a static library version of libc++, this is needed for essentially every test due to libc++ object files requiring it.

Also with libc++ built as a DLL, some tests directly call functions that are provided by msvcprt (such as std::set_new_handler), thus this fixes a number of tests in that configuration too.

Diff Detail

Event Timeline

mstorsjo created this revision.Mar 24 2021, 7:06 AM
mstorsjo requested review of this revision.Mar 24 2021, 7:06 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 24 2021, 7:06 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript

In the description the first sentence "This matches what". what -> when?

I'm not a Windows expert, so won't approve. However I don't see a real issue with the change.

libcxx/utils/libcxx/test/config.py
464

Is msvcprt required here?

In the description the first sentence "This matches what". what -> when?

No, the sentence is the way I intended it to - "this matches what we do elsewhere"

libcxx/utils/libcxx/test/config.py
464

Not sure - I'm not entirely sure of the full actual setup where this would be exercised. It might not be relevant here actually.

Ping - this makes the list of libraries linked here match the ones set in the main CMakeLists.txt, cf https://github.com/llvm/llvm-project/blob/d92b4956d6db8904f6a21c0e037dd5161b843b87/libcxx/CMakeLists.txt#L799-L802.

curdeius accepted this revision as: curdeius.Mar 26 2021, 4:22 AM
curdeius added a subscriber: curdeius.

LGTM.
At the first sight, I thought that the whole story of linking another C++ standard library to build/test another was strange, but finally, that makes sense (for the ABI), and it's not MSVC specific.

libcxx/utils/libcxx/test/config.py
433

Could you add a comment (somewhere) mentioning the corresponding flags in CMakeLists.txt, please?
They should probably be always in sync.

mstorsjo added inline comments.Mar 26 2021, 4:48 AM
libcxx/utils/libcxx/test/config.py
433

I could add a comment for the MSVC specific case that I'm editing. For the rest of this function, the whole concept of "add flags for linking ABI library" is handled quite differently between the main cmake build and the tests - for other ABI libraries, the necessary options are set in cmake/Modules/HandleLibCXXABI.cmake, while these MSVC specific ones are set in the toplevel CMakeLists.txt within an LIBCXX_TARGETING_MSVC case.

It's a bit iffy because part of these (ucrt, msvcrt) correspond to adding -lc and -lgcc (in toplevel CMakeLists.txt, to counter the fact that we're linking with -nodefaultlibs or -nostdlib), while others of them (msvcprt, maybe vcruntime) correspond to the C++ ABI library. Not entirely sure at what level it's "supported"/working to build for MSVC targets with a abi other than vcruntime.

There are people who build for the "windows-itanium" target, with an almost-msvc-like environment but with libcxxabi. I think some of such cases do it with some out-of-tree patches to libcxx though. Or maybe building libcxx with that configuration, with LIBCXX_CXX_ABI=libcxxabi works out of the box right now and we're just needlessly linking msvcprt (without actually ending up using anything from it?) in those cases, who knows. In any case, sorting out those bits is a rabbit hole I'd refrain from diving into at this point :-)

TL;DR, can add a comment for the MSVC specific case, but I'd refrain from making it too generic about things being more in sync than they really are.

mstorsjo added inline comments.Mar 26 2021, 5:15 AM
libcxx/utils/libcxx/test/config.py
433

Also, the ABI layering parts of "vcruntime" isn't exactly as clearcut and clean as one could want. If linking against DLL versions of that runtime, c++.dll ends up importing functions like` __std_terminate` and _CxxThrowException from vcruntime140.dll but things like __ExceptionPtrDestroy from msvcp140.dll (which is their full C++ lib).

So in one sense I guess the situation is like using libstdc++ as ABI library - as it's a full C++ library, but we only end up using the ABI bits from it.

mstorsjo retitled this revision from [libcxx] [test] Link against msvcprt in tests to [libcxx] [test] Link against msvcprt as C++ ABI library in tests.Mar 26 2021, 5:23 AM
mstorsjo edited the summary of this revision. (Show Details)

Ping for second approval

Ping for second approval

Mordante accepted this revision.Apr 4 2021, 6:05 AM

Since the changes only affect Windows and looks it looks like a general improvement. LGTM.

This revision is now accepted and ready to land.Apr 4 2021, 6:05 AM
This revision was landed with ongoing or failed builds.Apr 4 2021, 9:18 AM
This revision was automatically updated to reflect the committed changes.