[PATCH] D36810: Minimal runtime for UBSan.

[Vedant Kumar via Phabricator via llvm-commits]

vsk added subscribers: kubamracek, friss, zaks.anna, vsk.
vsk added a comment.

Have you explored the possibility of reducing the overhead of the regular runtime to an acceptable level?

- If it's too big, we can disable any heavy weight features you identify at compile-time.
- If it allocates or prints too much, we can add in a custom allocator or printing strategy.
- If it requires too much metadata to be inserted into user programs, we can devise a new, smaller encoding for the metadata. Or simply teach the runtime handlers to accept `nullptr`. This should also achieve the binary size savings you mentioned.

I have a strong preference towards having a single codebase for the runtime. An entirely separate runtime would impose a higher testing and maintenance burden. If having a separate runtime is really the only path forward, I would like to learn more about why the current runtime cannot be adapted to suit your use cases.



================
Comment at: compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cc:24
+#define HANDLER(name, msg)                                 \
+  INTERFACE void __ubsan_handle_##name##_minimal() {       \
+    message("ubsan: " msg "\n");                           \
----------------
eugenis wrote:
> pcc wrote:
> > There's a function type mismatch here I believe. If the idea is to reduce binary size, I'd imagine that we'd want to avoid passing the source location on the clang side.
> Good point. Completely forgot about that :)
I imagine that deduplication needs to be supported by a minimal runtime, to prevent e.g a tight for loop from spamming the UB log. How do you plan on accomplishing that without source locations -- perhaps by emitting a bitmap?


https://reviews.llvm.org/D36810