[all-commits] [llvm/llvm-project] d47315: [compiler-rt] Fix -shared-libsan usage with intern...

Joseph Huber via All-commits all-commits at lists.llvm.org
Thu Oct 1 11:59:15 PDT 2026


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: d47315ba62d6b572a2e6aa0dd7f74a3cc128a569
      https://github.com/llvm/llvm-project/commit/d47315ba62d6b572a2e6aa0dd7f74a3cc128a569
  Author: Joseph Huber <huberjn at outlook.com>
  Date:   2026-10-01 (Thu, 01 Oct 2026)

  Changed paths:
    M compiler-rt/lib/sanitizer_common/symbolizer/sanitizer_wrappers.cpp
    M compiler-rt/test/ubsan/TestCases/Misc/Posix/hsa-load-order.cpp
    A compiler-rt/test/ubsan/TestCases/Misc/Posix/shared-libsan-dso.cpp

  Log Message:
  -----------
  [compiler-rt] Fix -shared-libsan usage with internal symbolizer (#227717)

Summary:
https://github.com/llvm/llvm-project/pull/226551 exposed a preexisting
issue when using `-shared-libsan` nad the internal symbolizer builds.
The symbolizer will try to look up the symbol via `RTLD_NEXT`, which
goes in load order. If the sanitizer library is loaded *after* `libc.so`
then this `dlsym` call will miss it.

The solution is to have a fallback that checks using `RTLD_DEFAULT`.
This
should allow us to find the symbol in these exceptional cases. I don't
expect much fallout as this covers a case that currently returns `NULL`.
Loading it in means it could grab a reference ahead of the runtime that
was intended to be intercepted, but for this use-case I don't think this
will apply.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications


More information about the All-commits mailing list