This is an archive of the discontinued LLVM Phabricator instance.

[compiler-rt] [test] Use %clangxx for tests that use -x c++
ClosedPublic

Authored by mstorsjo on Apr 6 2023, 1:21 AM.

Details

Summary

When instrumenting C++ code, ubsan ends up referencing
the ubsan_type_hash_* object files, which require linking against
the C++ ABI library. When building with "clang -x c++", the code
is handled as C++, but the compiler still only links as if it was
C.

Change all cases of "%clang -x c++" into "%clangxx -x c++".

This fixes a lot of ubsan tests in mingw mode.

Diff Detail

Event Timeline

mstorsjo created this revision.Apr 6 2023, 1:21 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 6 2023, 1:21 AM
Herald added subscribers: Enna1, dberris. · View Herald Transcript
mstorsjo requested review of this revision.Apr 6 2023, 1:21 AM
Herald added a project: Restricted Project. · View Herald Transcript
Herald added subscribers: Restricted Project, jplehr, sstefan1. · View Herald Transcript
phosek accepted this revision.Apr 8 2023, 2:47 PM

To get the equivalent behavior to invoking clang++ with clang you need to use --driver-mode=g++ in addition to -x c++. I'm fine with using %clangxx as well.

This revision is now accepted and ready to land.Apr 8 2023, 2:47 PM

The change %clangxx makes sense but I am curious how %clang -x c++ broke only in mingw mode.

ubsan_type_hash_win.cpp is referenced by ubsan_handlers_cxx.cpp. Any idea how %clang -x c++ invocations extract the archive member corresponding to ubsan_handlers_cxx.cpp in mingw mode? AIUI ubsan_handlers_cxx.cpp is for some C++ specific -fsanitize= modes, which are unrelated to the modes used by these tests.

The change %clangxx makes sense but I am curious how %clang -x c++ broke only in mingw mode.

ubsan_type_hash_win.cpp is referenced by ubsan_handlers_cxx.cpp. Any idea how %clang -x c++ invocations extract the archive member corresponding to ubsan_handlers_cxx.cpp in mingw mode? AIUI ubsan_handlers_cxx.cpp is for some C++ specific -fsanitize= modes, which are unrelated to the modes used by these tests.

On Windows (both mingw and msvc mode), the sanitizers are linked in by adding linker directives to the object file - when compiling in C mode, it's /DEFAULTLIB:libclang_rt.ubsan_standalone-x86_64.a while C++ mode also brings in /DEFAULTLIB:libclang_rt.ubsan_standalone_cxx-x86_64.a.

So when the C++ source brings in libclang_rt.ubsan_standalone_cxx-x86_64.a, it loads __ubsan_handle_cfi_bad_type from there (instead of using the fallback default __ubsan_handle_cfi_bad_type_default within ubsan_handlers.cpp) and ends up bringing in ubsan_handlers_cxx.cpp.obj and ubsan_type_hash_itanium.cpp.obj.

If I forcibly link in libclang_rt.ubsan_standalone_cxx.a on Linux too, I end up with the same link error.