delcypher wrote: @vitalybuka
> > Should we just rename stuff of this patch into __clang_trap_msg ? > > Actually no. > > __clang_trap_msg_* is only for trap. __ubsan_check_* is for instructions > evaluating check (as now there is a bonus: that __ubsan_check_* works as > __clang_trap_msg_* on traps). > > Attaching __clang_trap_msg_* to evaluation code probably not nice. Agreed. `__clang_trap_msg` serves a very different purpose (show a human readable message in the debugger) to `__ubsan_check_` (to aid profiling). > > Now we can attach __ubsan_check_* to both - eval and trap. Later > __clang_trap_msg_* can be attached on top of our frame to trap. That seems reasonable to me. as long as the `__ubsan_check` name is stable we can teach LLDB to skip this frame when a trap is hit. > > I assume __clang_trap_msg_* can be as precise as __ubsan_check__, so we can > switch to that one from __ubsan_check__ for crash reports. By "switch to" do you mean remove ` __ubsan_check` from the debug info on the trap instruction and **only** use `__clang_trap_msg`? For now I think the implementation (on the clang side) would likely be simpler if we allowed both inline frames in the debug info. > > I guess we can land this one, as we can see clear way forward with both > features? SGTM. 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
