delcypher wrote: @PiJoules
> Moving forward, I think it would be good to gather consensus on a better > scheme with respect to verbose messages handled by the debugger. Rather than > baking a custom format into the function name, we think it's more portable > and straightforward to use standard dwarf features. If we don't end up using > DW_AT_description in this PR, I think it would be good to at least ensure > that using this mangled format isn't a permanent status quo and we leave room > for incremental improvements in the future towards a more portable > standardized approach. Such a scheme definitely needs more flushing out than > what I posted earlier in this thread, so I'll likely post an RFC on discourse > with a more formal proposal some time in the future. I don't think we are strongly tied to the mangled function name format (in fact we've already changed the mangling once internally already). If we do introduce a new approach based on `DW_AT_description` then provided we can have LLDB understand both the old (mangled function name) and new approach (uing `DW_AT_description`) for encoding the trap reasons for a few releases (so that newer debuggers can handle older binaries) then I suspect that would be fine. @Michael137 @adrian-prantl may want to chime in though. An RFC on a more fleshed out version of what you sketched out would be great. When writing it though please consider that UBSan is not the only use case for this. In particular * `-fbounds-safety` (implemented in the open source Swift fork of clang) uses this mechanism too in an incredibly similar way. * `__builtin_verbose_trap` (which is already adopted in libcxx IIRC) uses the current mechanism. * Swift uses a very similar mechanism for its traps but the implementation is independent from Clang. Swift's implementation is in fact the inspiration for how we implemented representing trap messages in Clang. If `DW_AT_description` just encodes a static string that would be general enough for `-fbounds-safety` and `__builtin_verbose_trap` but as soon as we start talking about "fake" arguments to the "fake" function in debug info then things get much more complicated and doesn't necessary generalize. https://github.com/llvm/llvm-project/pull/145967 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
