Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

implement a ubsan runtime for better error messages #22488

Open
wants to merge 18 commits into
base: master
Choose a base branch
from

Conversation

Rexicon226
Copy link
Contributor

closes #5163

So far, I've opted to copy the error messages that LLVM's ubsan runtime uses verbatim. I think they make sense, but we might be able to improve some of them.

As discussed on the Zulip, we've opted for the following strategies.

Regarding the logic for including the runtime, since ubsan-rt pulls in a lot of the standard library for the stack traces, I've set it up to do the following:

  • zig build-exe foo.c -> build libubsan.a and links
  • zig build-obj foo.c -> doesn't build anything, just emits references to ubsan runtime
  • zig build-lib foo.c -static -> build ubsan.o and link it
  • zig build-exe foo.zig bar.c -> import ubsan-rt into the ZCU
  • zig build-obj foo.zig bar.c -> import ubsan-rt into the ZCU
  • zig build-lib foo.zig bar.c -> import ubsan-rt into the ZCU

Regarding what defaults to use for including ubsan:

  • In Debug mode, the full runtime is included, with only a couple of specific checks disabled for reasons explained in Compilation.zig
  • In ReleaseSafe mode, the full runtime is disabled opting instead to trap on detected UB.
  • In other modes, ReleaseFast and ReleaseSmall, the ubsan runtime is not included in any capacity.

@mlugg has a proposal for allowing enabling other configurations of the ubsan, maybe he'll open it up as a proposal :)

also seems to work around aarch64 LLVM miscompilation 🤔
Unlike `compiler-rt`, `ubsan` uses the standard library quite a lot.
Using a similar approach to how `compiler-rt` is handled today, where it's
compiled into its own object and then linked would be sub-optimal as we'd
be introducing a lot of code bloat.

This approach always "imports" `ubsan` if the ZCU, if it exists. If it doesn't
such as the case where we're compiling only C code, then we have no choice other
than to compile it down to an object and link. There's still a tiny optimization
we can do in that case, which is when compiling to a static library, there's no
need to construct an archive with a single object. We'd only go back and parse out
ubsan from the archive later in the pipeline. So we compile it to an object instead
and link that to the static library.

TLDR;
- `zig build-exe foo.c` -> build `libubsan.a` and links
- `zig build-obj foo.c` -> doesn't build anything, just emits references to ubsan runtime
- `zig build-lib foo.c -static` -> build `ubsan.o` and link it
- `zig build-exe foo.zig bar.c` -> import `ubsan-rt` into the ZCU
- `zig build-obj foo.zig bar.c` -> import `ubsan-rt` into the ZCU
- `zig build-lib foo.zig bar.c` -> import `ubsan-rt` into the ZCU
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Give more info when a UB trap is detected in zig cc debug mode
1 participant