[clang] [ubsan] Add more -fsanitize-annotate-debug-info checks (PR #141997)

[Michael Buch via cfe-commits]

Michael137 wrote:

> While logically correct I think we might have to teach LLDB how to handle this. LLDB has a special "frame recognizer" where it looks for frames using this fake debug info mechanism (e.g. __builtin_verbose_trap) and it assumes the frame below it is the real source code and automatically selects this frame when trapping so that the user sees the correct source location when the trap is hit. If the frame below the fake frame isn't the user's code and is instead another fake frame this won't work properly.

Yea everything that  @delcypher said here is accurate from the LLDB-side. Here's the logic that LLDB uses to pick which frame to display: https://github.com/llvm/llvm-project/blob/9ba332f9963561bb5ac6933266afe38eb8fde8cd/lldb/source/Target/VerboseTrapFrameRecognizer.cpp#L22-L50

Currently we just pick the frame just above the fake inlined frame (and skip over any `std::` frames). We can definitely adjust the heuristic to accommodate the case where we have another fake frame above the UBSan trap one.

> It's probably possible to make LLDB work with which ever top frame we decide but we'd probably want the fake frame names be easily recognizable and stable so that LLDB's feature continues to work reliably.

Agreed, for the `__builtin_verbose_trap` we picked `__clang_trap_msg` as the prefix for the fake frame. And that's how LLDB knows to activate the frame recognizer: https://github.com/llvm/llvm-project/blob/9ba332f9963561bb5ac6933266afe38eb8fde8cd/lldb/source/Target/VerboseTrapFrameRecognizer.cpp#L145-L146

We'll want a similar prefix for any other fake frames that LLDB is supposed to recognize

> Given that -fsanitize-annotate-debug-info is off by default my suggestion is that @anthonyhatran land the simplest version of his patch possible by not concerning himself with  -fsanitize-annotate-debug-info at this stage. And after it's landed we can then decide how to make the two features interact in a way that the LLDB folks are happy with.

Agreed

https://github.com/llvm/llvm-project/pull/141997