How do you handle tricky FFI memory safety issues in production?

Hi guys ~

I'd like to share a project I've been developing and sincerely hope to receive feedback and guidance from compiler experts.

I'm building a static analysis tool focused on unsafe and FFI boundaries. The core idea is to make it completely language-independent. I don't care whether Rust calls C or Go calls C via cgo—ultimately, they're all LLVM IR. I only care about potential pointer leaks, lifetime issues, or undefined behavior near FFI boundaries.

It differs from general-purpose tools in the following ways:

Most general-purpose static analyzers either ignore external function boundaries or completely crash when they encounter them. On the other hand, if you try to analyze the entire compiled IR, you'll quickly realize it's a nightmare—the compiler injects a huge amount of redundant information. Scanning everything consumes staggering computational resources.

The problem I'm currently trying to solve is: how to reduce noise, i.e., skip compiler artifacts and strictly track data flow across boundaries.

I'd like to solicit suggestions or ideas on the following questions:

  1. Has anyone tried mapping language-specific safety invariants (e.g., Rust's borrowing rules) onto pure LLVM IR primitives for verification?

  2. In production environments, what common FFI boundary cases have you encountered that traditional static analysis often misses?

If you are interested in this approach, or have any suggestions on denoising patterns in the LLVM IR pipeline, please leave a comment.

Thank you!