delcypher wrote: @thurstond
> I agree it can be useful in many cases, but it could also make the debug info > unbearably large. (Anecdata: Big Google disables the current trap-reasons > annotations in their internal toolchain, because it made the debug info up to > 15% larger, even without these expressions.) > > Would the ability to control it via a flag be useful? (e.g., either convert > "-fsanitize-debug-trap-reasons" into a ternary flag - something like > "off"/"basic"/"detailed" - or add a separate flag.) Just my tuppence. I don't > object to the current patch, even without adding the flag, since users can > still disable trap reasons entirely. Hmm interesting. We didn't expect the debug info to increase that much based on the [measurements done here](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. I can see there being an argument to support the "basic" trap reasons to allow more another option in the debugability vs debug info size space. I would like to make "detailed" the default though. Given that there hasn't been a compiler release with the `-fsanitize-debug-trap-reasons` yet if we are going to change the clang to be a ternary flag then now would be a good time to do it. I'll investigate making the change. https://github.com/llvm/llvm-project/pull/154618 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
