krabcake: Successfully send intrinsics::assume data to Valgrind

[bryangarza]

This patch adds support to send the bool in std::intrinsics::assume to Valgrind by inserting a Valgrind Client Request using a MirPass.

Depends on pnkfelix/krabcake-vg#2

How to test: use the -Z instrument_krabcake flag. You can compile something simple like:

#![feature(core_intrinsics, intrinsics)]
fn main() {
    let mut x = 45;
    let y = &mut x;
    println!("{y}");
    unsafe {
        std::intrinsics::assume(x == 45);
    }
}

Running krabcake:

~/projects/default/krabcake/bin/valgrind --tool=krabcake ./my_simple_program
==75859== Krabcake, the Rust UB detection tool
==75859== Copyright (C) 2023, and GNU GPL'd by Felix S. Klock.
==75859== Using Valgrind-3.21.0.GIT and LibVEX; rerun with -h for copyright info
==75859== Command: ./my_simple_program
==75859==
Hello world (from `rs_hello/src/lib.rs`)! printed: 42
45
--75859-- kc_handle_client_request, dispatching client request code 4b430008
--75859-- kc_handle_client_request, handle INTRINSICS_ASSUME 1 0 0 0 0
==75859==
==75859== For lists of detected and suppressed errors, rerun with: -s
==75859== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[bryangarza]

TODO: Get the bool from the existing MIR intrinsics::assume itself

[pnkfelix]

namely, extract it from the _operand parameter you are passing above, right?

[bryangarza]

correct

[pnkfelix]

Hmm. Question: Should we be extending libcore with stuff like this?

Here are our options, as I see them:

1. Client code code carries its own copy of the relevant enum (that's what we're doing now in https://github.com/pnkfelix/krabcake/blob/f353b59e7af59d055935022c6c3f72adf3a1e53e/sb_rs_port/src/krabcake.rs#L7 ). This is fine for demos, but a non-starter for our target audience for krabcake (where its supposed to be "just recompile and go")
2. Rustc Compiler has access to all the integers that are used for the relevant enum, and embeds those values directly into the object code that gets generated. Demo code cannot refer to the enum itself from its source code. This is what I had originally envisaged.
3. libcore defines the enum, and either the Rustc Compiler includes accesses to the elements of that enum in the code it injects (which is what I expect for the majority of the cases), or the client code can access the values itself for its own purposes.

I'm trying to envisage the cases where we would want to do option (3). The main benefit of option (3) AFAICT is that you get to write source code in your demos that reference the enum values, so you have more control over fine-tuning (if you wanted to e.g. experiment with alternative protocols for how you interact with the valgrind krabcake tool).

But I think in all such cases, I would opt to actually include a copy of the relevant enum in the source code (i.e. option (1.) over option (3.)

@bryangarza did you adopt this strategy because it was simpler to implement than option (2.)? Or am I missing some benefit of option (3.)?

[bryangarza]

embeds those values directly into the object code that gets generated

Not sure I quite follow what you mean in option 2; do you mean basically being able to have the MirPass insert the krabcake request into the MIR but without needing a Lang Item? (example)

Or do you mean some method that doesn't use a MirPass?

---

did you adopt this strategy because it was simpler to implement than option (2.)? Or am I missing some benefit of option (3.)?

The reason I made it a lang item is so that it would be more maintainable to have most of the logic defined as Rust code instead of needing to handwrite a lot of MIR. Also, I created a separate data-type KrabcakeRequest so that we don't couple the C enum to the enum that is used in rustc, since as you said, we could in the future change the format or approach that is used in rustc itself independently of what the request looks like when sent to Valgrind (or we could even use something other than/in addition to Valgrind)

[bjorn3]

We could have a terminator or intrinsic for emitting valgrind client requests, right? That would probably be more efficient as you can avoid the overhead of a non-inlineable call. Valgrind is relatively slow, so every bit helps I guess.