[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