Add rust support for introspector

[nathaniel-brough]

Hey so I'm interested in adding rust support. I think I've got a rough idea as to how this might be doable. But I'd love to get some feedback from someone a little more knowledgeable on introspector before I get started. As far as I can tell there are a few metrics that need to be collected and tied together somehow;

• Code coverage (collected by oss-fuzz)
• Cyclomatic complexity
• Callgraphs (for reachable complexity/fuzz-blockers)

I'm sure there are other challenges in terms of coaxing all of this data into a format that introspector can work with as well. Am I missing anything critical here?

Code coverage

This is already collected by oss-fuzz.

Callgraphs

This can be acheived using rust-analyzer plus a specialised client for the language server that recursively queries the outgoing-calls endpoint. This would have the nice side effect that as the outgoing calls endpoint is added to other language servers the code should be portable or at least easy enough to adapt to other languages e.g. clangd is in the process adding support for this endpoint, clojure already supports it. Not suggesting here that this approach should replace existing clang/llvm-opt callgraphs just mentioning for completeness.

Cyclomatic complexity

This can be implemented with rust-code-analysis, worth noting that this also supports a bunch of other languages besides rust as well as metrics other than cyclomatic complexity.

[DavidKorczynski]

This sounds great!

Let me go a bit more over this and assist with scoping out for Rust. See LanguageImplementation for details on how to add a new language.

Rust relies on LLVM/Clang? Do you know if regular LLVM LTO passes can run on Rust code? We may be able to use the existing LLVM frontend

[nathaniel-brough]

Let me go a bit more over this and assist with scoping out for Rust. See LanguageImplementation for details on how to add a new language.

Cool I missed that, I'll take a read over the next few days.

Rust relies on LLVM/Clang? Do you know if regular LLVM LTO passes can run on Rust code? We may be able to use the existing LLVM frontend

I've never tried this, and tbh I'm not really up to speed on how LTO passes work beyond them just being a plugin for the linker. But I did come across something that sounds like what you are mentioning, while looking at LTO with rust/c++. Reading over it a gain it looks somewhat promising but I'd have to a do a deeper dive.

[nathaniel-brough]

So after reading over that doc that you've mentioned, I had missed a couple of things in my original assesment. The only open question I have is, how we would implement the branch profiles section of the project wide yaml file. Evaluating control flow in rust is reasonably complex with things like;

• match statements
• macros
• "standard" control flow (if/else, loops etc.)

One approach would be to expand out each macro e.g. cargo expand path::to::module but that has other issues; like which line do you attribute the branch to in the non-expanded source code.

[DavidKorczynski]

In terms of control flow, then ideally because Rust is based on LLVM we could do the analysis directly on LLVM IR and use the logic from https://github.com/ossf/fuzz-introspector/tree/main/frontends/llvm to do all of the control-flow analysis -- I could take a look at this sometime in Feb I think.

[0xalpharush]

There is an nightly flag to load llvm passes from a shared object
From rust-lang/rust#127577:

This option currently only works on targets that use an llvm dylib, which is just x86_64-unknown-linux-gnu. On other targets LLVM is linked statically, and symbols needed by plugins are not visible.