UBSan trap runtime missing encoding

[Ivan-Velickovic]

Zig Version

0.14.0

Steps to Reproduce and Observed Behavior

My understanding is Zig introduced its own UBSan runtime with 0.14.0 that is now used instead of LLVM's runtime.

I use Zig to cross-compile C code in a freestanding environment so instead of printing out a stack trace etc I'm used to just getting an instruction that causes an exception when UBSan detects UB.

On ARM64 (and potentially other architectures), LLVM would encode the UB cause into the brk instruction. In a freestanding environment then you can decode it to at least get a hint of what could be going wrong.

Does the Zig runtime intend to provide that behaviour?

Expected Behavior

Trap instruction has same encoding as Zig 0.13.0.

[Rexicon226]

I agree that this is a perfectly valid use case. Our idea was to have -fsanitize-c -fno-ubsan-rt enable the minimal runtime (the one that traps), however as it works right now, you can only do that in ReleaseSafe, which is clearly not optimal. See this issue: #23216, for tracking progress on that fix.

[Ivan-Velickovic]

Ah okay cool, thanks. I'll retry once that issue is fixed.

[alexrp]

On ARM64 (and potentially other architectures), LLVM would encode the UB cause into the brk instruction. In a freestanding environment then you can decode it to at least get a hint of what could be going wrong.

Just to be clear, are you saying that Zig 0.13.0 used to do this? If so, then this would indeed just be a duplicate of #23216.

[Ivan-Velickovic]

Just to be clear, are you saying that Zig 0.13.0 used to do this? If so, then this would indeed just be a duplicate of #23216.

0.14.0 still traps, it just doesn't trap the same way as 0.13.0. Is that what #23216 is about, I thought it was asking for the ability to only trap and not have the whole Zig runtime library?

[alexrp]

Ok, to be completely clear, I'm distinguishing between these cases:

1. Trapping with an invalid instruction (or some moral equivalent).
2. Trapping with an invalid instruction that encodes the failure type.
3. Trapping by calling into the UBSan runtime.

Which of these 3 are you seeing with 0.13.0 and 0.14.0?

[Ivan-Velickovic]

Okay so I don't think I quite understand trapping with an invalid instruction vs trapping by calling into the UBSan runtime. With my system I just use the defaults for C compilation, so how 0.13.0 vs 0.14.0 are generating invalid instructions I am not sure, but with both I get a brk instruction but only with 0.13.0 do I see a brk instruction that encodes the failure type. Hope that helps clear things up.

[alexrp]

Ok, it seems that the UBSan runtime just ends up calling the panic handler. What does your panic handler do? (I assume you have a custom handler in place since this is freestanding?)

[ikskuh]

Ok, it seems that the UBSan runtime just ends up calling the panic handler. What does your panic handler do? (I assume you have a custom handler in place since this is freestanding?)

Assuming they don't have a valid panic handler, the default handler will do a @trap() call

This happens when no Zig source code is compiled, but just C code.

[Ivan-Velickovic]

Ok, it seems that the UBSan runtime just ends up calling the panic handler. What does your panic handler do? (I assume you have a custom handler in place since this is freestanding?)

No panic handler.

[alexrp]

Ok, then I think this is simply a duplicate of #23216.