Changes I needed to get Siderophile working

[defuse]

No description provided.

[CLAassistant]

All committers have signed the CLA.

[disconnect3d]

See my question. Other than that, the changes looks good.

[disconnect3d]

Any particular reason why we remove -C inline-threshold=9999?

[disconnect3d]

@rozbb btw why do we use inline threshold of 9999?

[defuse]

I removed it because it was causing functions to be inlined, so the generated call graph was missing all of the functions. (Setting it to 0 didn't work because that still allows one level of inlining). Here's the program I was trying to analyze:

use std::io::Cursor;
use byteorder::{BigEndian, ReadBytesExt};

pub fn main(v: Vec<u8>) {
    println!("Hello, world!");
    foobar(v);
}

pub fn foobar(v: Vec<u8>) {
    let mut rdr = Cursor::new(v);
    assert_eq!(0.01, rdr.read_f64::<BigEndian>().unwrap());
}

Without this change it got as far as realizing the read_f64 uses unsafe code and it added that to nodes_to_taint.txt, but the callgraph in unmangled_callgraph didn't show that main() calls foobar, so the final trace_unsafety.py step produced no useful result.

[disconnect3d]

I was able to reproduce this (by changing the example a bit e.g. assuming a proper fn main declaration) and confirmed (by reversing the produced binaries) that with the -C inline-threshold=9999 flag the foobar call got inlined into main and when the flag is not passed, the inlining did not happen.

Though, my questions now are:

• Is it enough to remove the flag or maybe it is better to pass a value of 0? This grcov PR comment suggests that passing 0 should disable inlining while this Rust issue suggests that it might not be enough (I am not sure here)?
• Why was this flag introduced in the first place? Maybe @rozbb can jump here :P.

Also for reference:

• https://doc.rust-lang.org/beta/rustc/codegen-options/index.html#inline-threshold

[disconnect3d]

According to the rustc codegen-options specification, the opt-level=0 should also enable inline-threshold=0.

So when I don't pass the inline-threshold flag, the inlining doesn't happen as expected. If I pass it explicitly with 0 value, the inlining occurs. This is weird.

[rozbb]

Ah, I didn't think that setting the variable to 0 would work. I forgot why, but this seems like a good change.

[reaperhulk]

Interesting, I had no idea that -Cinline-threshold=0 allows one level of inlining. Does LLVM/rustc document that behavior anywhere?

[disconnect3d]

allows one level of inlining

Does it? If you looked at the Rust lang docs I linked above, the N/A, only inlines always-inline functions is for the opt level of 0 and not necessarily the -Clinline-threshold=0 (which btw I think is a bit misleading).

Does LLVM/rustc document that behavior anywhere?

I couldn't find any other place except of the docs or rustc -C help.

Also there is -C llvm-args=-inline-threshold=0 too as in the Rust issue linked above. I don't even...

[disconnect3d]

Merging this for now. We need proper CI/tests for such things, which I am going to add later on.