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

Reply via email to