Fix typeinfo for undefined sanitizer

[MBkkt]

This happened to me when I compiled my code on x86_64 linux (ubuntu 24.04) with clang-18 and everything except clang, compiler_rt, glibc built from source (llvm 19, llvm source) in debug (-O1)

I found this solution and luckily it works!
emscripten-core/emscripten#13367 emscripten-core/emscripten#13330

I saw that issue is abandoned, so I decided to try to push it in upstream

[github-actions]

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

[llvmbot]

@llvm/pr-subscribers-libcxx

Author: Valery Mironov (MBkkt)

Changes

This happened to me when I compiled my code on x86_64 linux (ubuntu 24.04) with clang-18 and everything except glibc built from source (llvm 19, llvm source)

I found this solution and luckily it works!
emscripten-core/emscripten#13367 emscripten-core/emscripten#13330

I saw that issue is abandoned, so I decided to try to push it in upstream

---

Full diff: https://github.com/llvm/llvm-project/pull/121228.diff

1 Files Affected:

• (modified) libcxx/include/typeinfo (+2-1)

diff --git a/libcxx/include/typeinfo b/libcxx/include/typeinfo
index 799c6ebd5ecbbf..a900ccaf7e24bb 100644
--- a/libcxx/include/typeinfo
+++ b/libcxx/include/typeinfo
@@ -315,7 +315,8 @@ public:
 
   _LIBCPP_HIDE_FROM_ABI size_t hash_code() const _NOEXCEPT { return __impl::__hash(__type_name); }
 
-  _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX23 bool operator==(const type_info& __arg) const _NOEXCEPT {
+  // We need to inline this code because otherwise we will get a stack overflow with undefined sanitizer.
+  _LIBCPP_HIDE_FROM_ABI _LIBCPP_ALWAYS_INLINE _LIBCPP_CONSTEXPR_SINCE_CXX23 bool operator==(const type_info& __arg) const _NOEXCEPT {
     // When evaluated in a constant expression, both type infos simply can't come
     // from different translation units, so it is sufficient to compare their addresses.
     if (__libcpp_is_constant_evaluated()) {

[github-actions]

⚠️ C/C++ code formatter, clang-format found issues in your code. ⚠️

You can test this locally with the following command:

git-clang-format --diff 815343e7dd32cc4c5c903ac52daf87aaa4e4cd6e 3d8fb18949dba038667e6d8983948b85a73cefdb --extensions  -- libcxx/include/typeinfo

View the diff from clang-format here.

diff --git a/libcxx/include/typeinfo b/libcxx/include/typeinfo
index a900ccaf7e..6bca852e21 100644
--- a/libcxx/include/typeinfo
+++ b/libcxx/include/typeinfo
@@ -316,7 +316,8 @@ public:
   _LIBCPP_HIDE_FROM_ABI size_t hash_code() const _NOEXCEPT { return __impl::__hash(__type_name); }
 
   // We need to inline this code because otherwise we will get a stack overflow with undefined sanitizer.
-  _LIBCPP_HIDE_FROM_ABI _LIBCPP_ALWAYS_INLINE _LIBCPP_CONSTEXPR_SINCE_CXX23 bool operator==(const type_info& __arg) const _NOEXCEPT {
+  _LIBCPP_HIDE_FROM_ABI _LIBCPP_ALWAYS_INLINE _LIBCPP_CONSTEXPR_SINCE_CXX23 bool
+  operator==(const type_info& __arg) const _NOEXCEPT {
     // When evaluated in a constant expression, both type infos simply can't come
     // from different translation units, so it is sufficient to compare their addresses.
     if (__libcpp_is_constant_evaluated()) {

[ldionne]

This patch does not make sense to me. It seems we're putting a band-aid on something a lot more serious. I'd much rather fix the underlying issue instead.

[MBkkt]

I'd much rather fix the underlying issue instead.

Ofc, but it's unrealistic, no one cares

[philnik777]

I'd much rather fix the underlying issue instead.

Ofc, but it's unrealistic, no one cares

You seem to care.

[MBkkt]

I'd much rather fix the underlying issue instead.

Ofc, but it's unrealistic, no one cares

You seem to care.

@philnik777

I mean, I don't really believe someone will spend time to investigating the underlying problem in near future.
I'm personally not familiar with the internals of the compiler runtime/llvm/clang, and unfortunately I have other priorities.

I think these changes just fix the issue that already happened.
And if no one plan to investigate this in near future, probably better to use not "right" fix and have issue/task/todo/whatever to investigate it later, maybe someone sometime will do this

[ldionne]

@MBkkt The point I was trying to make (which I didn't say explicitly but should have) is that this issue seems to be emscripten specific. It's not reproducing with ubsan in normal setups AFAICT. If someone from emscripten investigates the underlying issue and provides a reproducer that is not emscripten specific (if that's possible), we'd be happy to take over and fix the problem properly, whatever that means. But I'm not comfortable with taking a patch that changes our code:

• Without understanding what we're actually fixing
• Without having any test to prevent a regression
• Without having a test that confirms we're actually fixing the issue

Sorry, I know you just want this simple fix to be applied, but we must have some kind of bar for accepting contributions.

Closing for now, but we'd be happy to fix the underlying issue if someone can provide a reproducer that is not emscripten specific.

[MBkkt]

The point I was trying to make (which I didn't say explicitly but should have) is that this issue seems to be emscripten specific.

It's not, I wrote in description, anyone can just build libc++ from source with -O1 and undefined sanitizer
But anyway you see what you want to see, so I don't want to continue this discussion.

My project is completely unrelated to wasm or emscripten, it's just statically linked project with build from source, which use llvm-project cmake for libc++.
Most devs doesn't build libc++ in their projects.
Some of devs who build, doesn't use sanitizers/doesn't use sanitizers for libc++
Some of devs who build and use sanitizers for libc++ doesn't use debug with sanitizers.

That's why find another example of this issue is not simple, even this example in emscripten caused not by debug, but -Oz.
I just google the issue that happened in my code, and find almost the same issue in emscripten with solution which also worked for me.

[MBkkt]

I think the real issue is that when this function doesn't inline it is somehow ignore -fno-sanitize=vptr

https://android.googlesource.com/platform//external/v8/+/27d3291ef11ea9043d7b09525245fd30cd31b20d/tools/ubsan/vptr_blacklist.txt#9
and same for chromium.

Because according to my compile_commands.json I built without vptr this file (because using llvm-project cmake)
But it still failed with same issue (without provided patch, I also tried manually mark with no-vptr related functions in call stack)
I agree that my build is unusual, but I'm pretty sure this issue doesn't depend on anything except inline this function or not.
Maybe it's possible to easy reproduce this issue with making this function no-inline for ubsan build of libc++

{
  "directory": "/xxx/build",
  "command": "/usr/bin/clang++-18 -DHAVE___CXA_THREAD_ATEXIT_IMPL -DLIBCXX_BUILDING_LIBCXXABI -DNDEBUG -D_LIBCPP_BUILDING_LIBRARY -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS=\"\" -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCXXABI_BUILDING_LIBRARY -D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/xxx/llvm/libunwind/include -I/xxx/llvm/libcxxabi/../libcxx/src -I/xxx/llvm/libcxxabi/include -isystem /xxx/build/llvm/runtimes/include/c++/v1 -fsized-deallocation -fvisibility-inlines-hidden -fno-omit-frame-pointer -O1 -fsanitize=undefined -fno-sanitize=vptr,function -fno-sanitize-recover=all -fdiagnostics-color  -O0 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fno-limit-debug-info -g3 -fstandalone-debug -fdebug-macro -glldb -std=c++23 -nostdinc++ -fstrict-aliasing -funwind-tables -DNDEBUG -fvisibility=hidden -fvisibility-global-new-delete=force-hidden -o llvm/runtimes/libcxxabi/src/CMakeFiles/cxxabi_static_objects.dir/private_typeinfo.cpp.o -c /xxx/llvm/libcxxabi/src/private_typeinfo.cpp",
  "file": "/xxx/llvm/libcxxabi/src/private_typeinfo.cpp",
  "output": "llvm/runtimes/libcxxabi/src/CMakeFiles/cxxabi_static_objects.dir/private_typeinfo.cpp.o"
},

[ldionne]

It's not, I wrote in description, anyone can just build libc++ from source with -O1 and undefined sanitizer
But anyway you see what you want to see, so I don't want to continue this discussion.

Ah, no, I simply missed that. I do a lot of reviews every day and the only way that works is for me to read PR descriptions with varied levels of care depending on the PR. In this case, I read too fast and jumped to the links, and I didn't see that you were able to reproduce this issue on non-emscripten. That changes a lot. Let's follow-up in #122389

[MBkkt]

@ldionne thanks and sorry, I was too emotional about this.

I hope noinline will be enough to reproduce, if not, I will experiment a little and will try to investigate on what it depends