thurstond 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=`)? Yes, it is off by default. > Do you have plans to switch it on by default? I don't have plans to switch it on by default for upstream. > 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. I believe they will work together and provide slightly different information. `-fsanitize-annotate-debug-info` is added during the SanitizerScope, so it encompasses all the UBSan-check instructions. Since @anthonyhatran's feature modifies `CodeGenFunction::EmitTrapCheck`, it will only annotate a subset of the instructions. IIUC if both are active and the debugger reaches the trap, `-fsanitize-annotate-debug-info` will have the second-top-most frame, while @anthonyhatran's feature will have the top-most frame, which is logically correct. If the debugger is at slightly prior to the trap, `-fsanitize-annotate-debug-info` will have the top-most frame. 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
