You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[UBSan][BoundsSafety] Implement support for more expressive "trap reasons"
In 29992cf (llvm#145967) support was added
for "trap reasons" on traps emitted in UBSan in trapping mode (e.g.
`-fsanitize-trap=undefined`). This improved the debugging experience by
attaching the reason for trapping as a string on the debug info on trap
instructions. Consumers such as LLDB can display this trap reason string
when the trap is reached.
A limitation of that patch is that the trap reason string is hard-coded
for each `SanitizerKind` even though the compiler actually has much more
information about the trap available at compile time that could be shown
to the user.
This patch is an incremental step in fixing that. It consists of two
main steps.
**1. Introduce infrastructure for building trap reason strings **
To make it convenient to construct trap reason strings this patch
re-uses Clang's powerful diagnostic infrastructure to provide a
convenient API for constructing trap reason strings. This is achieved
by:
* Introducing a new `Trap` diagnostic kind to represent trap
diagnostics in TableGen files.
* Adding a new `CodeGen` diagnostic component. While this part probably
isn't technically necessary it seemed like I should follow the
existing convention used by the diagnostic system.
* Adding `DiagnosticCodeGenKinds.td` to describe the different trap
reasons.
* Add the `RuntimeTrapDiagnosticBuilder` class to provide an interface
for constructing trap reason strings and the trap category. Note this
API while similar to `DiagnosticBuilder` has different semantics which
are described in the code comments. In particular the behavior when
the destructor is called is very different.
* Adding `CodeGenModule::RuntimeDiag()` as a convenient constructor for
the `RuntimeTrapDiagnosticBuilder`.
This use of the diagnostic system is a little unusual in that the
emitted trap diagnostics aren't actually consumed by normal diagnostic
consumers (e.g. the console). Instead the `RuntimeTrapDiagnosticBuilder`
is just used to format a string, so in effect the builder is somewhat
analagous to "printf". However, re-using the diagnostics system in this
way brings a several benefits:
* The powerful diagnostic templating languge (e.g. `%select`) can be
used.
* Formatting Clang data types (e.g. `Type`, `Expr`, etc.) just
work out-of-the-box.
* Describing trap reasons in tablegen files opens the door for
translation to different languages in the future.
* The `RuntimeTrapDiagnosticBuilder` API is very similar to
`DiagnosticBuilder` which makes it easy to use by anyone already
familiar with Clang's diagnostic system.
While UBSan is the first consumer of this new infrastructure the intent
is to use this to overhaul how trap reasons are implemented in the
`-fbounds-safety` implementation (currently exists downstream).
**2. Apply the new infrastructure to UBSan checks for arithmetic overflow**
To demonstrate using `RuntimeTrapDiagnosticBuilder` this patch applies
it to UBSan traps for arithmetic overflow. The intention is that we
would iteratively switch to using the `RuntimeTrapDiagnosticBuilder` for
all UBSan traps where it makes sense in future patches.
Previously for code like
```
int test(int a, int b) { return a + b; }
```
The trap reason string looked like
```
Undefined Behavior Sanitizer: Integer addition overflowed
```
now the trap message looks like:
```
Undefined Behavior Sanitizer: signed integer addition overflow in 'a + b'
```
This string is much more specific because
* It explains if signed or unsigned overflow occurred
* It actually shows the expression that overflowed
This seems a lot more helpful.
One possible downside of this approach is it may blow up Debug info size
because now there can be many more distinct trap reason strings. If this
is a concern we may want to add a flag to make it possible to continue
to use the original hard-coded trap messages to avoid increasing the
size of Debug info.
rdar://158612755
0 commit comments