delcypher wrote: @thurstond So there is a significant overlap here with what my GSoC student (@anthonyhatran) is working on right now (CC @MiB137). The project was proposed [here](https://llvm.org/OpenProjects.html#clang-improve-trapping-ubsan-2025).
During @anthonyhatran 's GSoC project he will be adding "trap reasons" to UBSan traps so that they are easier to debug when the debugger is attached. The intention is it this will be on by default and it will use the `CGDebugInfo::CreateTrapFailureMessageFor` facility (originally created for `__builtin_verbose_trap` and `-fbounds-safety`) which will be called in `CodeGenFunction::EmitTrapCheck`. Given that `CGDebugInfo::CreateTrapFailureMessageFor` and `CGDebugInfo::CreateSyntheticInlineAt` use the same underlying mechanism (fake inline frame) it seems that we might run into problems if both are used at the same time because they will both try to add a fake inline frame to the debug info on the trap instruction. Which ever fake inline frame ends on top will claim it is inlined in to the other fake inline frame which probably won't work in the debugger as intended. I'd like to make sure we don't step on each others toes here. Am I right in understanding that the fake debug info added in this PR is off by default (i.e. requires `fsanitize-annotate-debug-info=`)? Do you have plans to switch it on by default? What do you think the correct behavior should be when @anthonyhatran's feature (which we intend to be on by default) is used with `-fsanitize-annotate-debug-info=`? One option is to disable the feature that @anthonyhatran's feature in that case. https://github.com/llvm/llvm-project/pull/141997 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
