[Lldb-commits] [clang] [lldb] [UBSan][BoundsSafety] Implement support for more expressive "trap reasons" (PR #154618)
Michael Buch via lldb-commits
lldb-commits at lists.llvm.org
Tue Aug 26 13:11:10 PDT 2025
Michael137 wrote:
> > We didn't expect the debug info to increase that much based on the [#145967 (comment)](https://github.com/llvm/llvm-project/pull/145967#issuecomment-3099264478). Are they using some variant of -fno-sanitize-merge by any chance? Typically in optimized builds the trap instructions in each function get merged which results in the "trap reasons" in debug info being dropped and thus the "trap reasons" have a much smaller impact.
>
> Ah, the ~15% debug info overhead is for debug builds, which are unoptimized (-O0).
>
> Most of the other build modes at Google that have optimizations enabled turn off debug info. If I forcibly enable both optimizations and debug info, I do get much lower overheads in the same ballpark as [#145967 (comment)](https://github.com/llvm/llvm-project/pull/145967#issuecomment-3099264478)
Don't want to derail the review of this PR too much, but I am curious about the debug-info increase. A breakdown of section size increases would be interesting, if those are available. I don't have a good intuition for how many traps are emitted for real-world projects though, so if we emit a huge amount of them that would add up. I think the numbers we collected was for an unoptimized build (correct me if I'm wrong @delcypher). Also, aren't (at least some of) the trap instructions, disabled on unoptimized builds? But sounds like there's enough of them still emitted in unoptimized builds where it does get noticeable.
https://github.com/llvm/llvm-project/pull/154618
More information about the lldb-commits
mailing list