31–40 of 110 posts
Earlier quoted context omitted.
Hallelujah. This has been a pain point for anyone who tried to build rustc on non-tier1 platforms (musl as host, etc.).
Even on those platforms, it's helpful for distros, who only want one package, not a separate bootstrapping package. I'm real glad we're doing it.
Any idea as to why the following requirement? This will limit Afl.rs users quite a bit. afl.rs needs to compile against a version of LLVM that matches rustc's. The easy solution (if you can wait on a slow build) is to build rustc from source and put it in your PATH. Then afl.rs's build script will find llvm-config automatically. Otherwise, the environment variable LLVM_CONFIG should hold the path to llvm-config when…
Author here. AFL is coverage-guided fuzz testing (fuzz testing that relies on code coverage). Someone (not me) wrote an "LLVM pass" that loops through the generated LLVM IR for any LLVM-compiled program and injects the necessary AFL instrumentation such that AFL can work on it: https://github.com/mirrorer/afl/blob/master/llvm_mode/afl-ll... Since Rust uses LLVM when compiling a binary, all afl.rs does is incorporate…
Earlier quoted context omitted.
This is unfair. AFL support for Rust is in fact better than that for gcc because Rust at least provides a plugin interface that doesn't require you to have its sources lying around -- the GCC support instruments the assembly instead of compiler IR, which is far less effective. Rust nightly at least has proper afl support, gcc doesn't. It works for clang because llvm plugins in clang are stable, but we could get there…
Every time someone posts a cool Rust library, most of the time it makes use of nightly. How come can I advocate Rust to serious enterprise customers, if I have to justify using nightlies to make use of such tooling? Apparently downvoting every time someone mentions the issue with nightly being required is fair.
Earlier quoted context omitted.
This is unfair. AFL support for Rust is in fact better than that for gcc because Rust at least provides a plugin interface that doesn't require you to have its sources lying around -- the GCC support instruments the assembly instead of compiler IR, which is far less effective. Rust nightly at least has proper afl support, gcc doesn't. It works for clang because llvm plugins in clang are stable, but we could get there…
Every time someone posts a cool Rust library, most of the time it makes use of nightly. How come can I advocate Rust to serious enterprise customers, if I have to justify using nightlies to make use of such tooling? Apparently downvoting every time someone mentions the issue with nightly being required is fair.
Examples? Examples that aren't tools, that is. The main example I can think of is serde, and that works on stable (just works better on nightly).
What's wrong with nightly for using tooling? You don't have to keep updating, you can pin to a nightly from a particular date. You can use rustup.rs to switch to stable locally if you need to.
I said it's unfair, because gcc has worse issues here, and everyone probably agrees that gcc is "enterprise ready".
Earlier quoted context omitted.
Every time someone posts a cool Rust library, most of the time it makes use of nightly. How come can I advocate Rust to serious enterprise customers, if I have to justify using nightlies to make use of such tooling? Apparently downvoting every time someone mentions the issue with nightly being required is fair.
> Every time someone posts a cool Rust library, most of the time it makes use of nightly. Examples? Examples that aren't tools, that is. The main example I can think of is serde, and that works on stable (just works better on nightly). What's wrong with nightly for using tooling? You don't have to keep updating, you can pin to a nightly from a particular date. You can use rustup.rs to switch to stable locally if you…
Usually it is set in stone and only updated every few IT upgrade cycles.
What the devs get on their machines is that and nothing more.
Earlier quoted context omitted.
Every time someone posts a cool Rust library, most of the time it makes use of nightly. How come can I advocate Rust to serious enterprise customers, if I have to justify using nightlies to make use of such tooling? Apparently downvoting every time someone mentions the issue with nightly being required is fair.
You can write your own code in stable Rust while using tooling that works on nightly. Rustup.rs makes it very easy to switch between stable and nightly.
Earlier quoted context omitted.
This is unfair. AFL support for Rust is in fact better than that for gcc because Rust at least provides a plugin interface that doesn't require you to have its sources lying around -- the GCC support instruments the assembly instead of compiler IR, which is far less effective. Rust nightly at least has proper afl support, gcc doesn't. It works for clang because llvm plugins in clang are stable, but we could get there…
Every time someone posts a cool Rust library, most of the time it makes use of nightly. How come can I advocate Rust to serious enterprise customers, if I have to justify using nightlies to make use of such tooling? Apparently downvoting every time someone mentions the issue with nightly being required is fair.
Earlier quoted context omitted.
This is unfair. AFL support for Rust is in fact better than that for gcc because Rust at least provides a plugin interface that doesn't require you to have its sources lying around -- the GCC support instruments the assembly instead of compiler IR, which is far less effective. Rust nightly at least has proper afl support, gcc doesn't. It works for clang because llvm plugins in clang are stable, but we could get there…
Every time someone posts a cool Rust library, most of the time it makes use of nightly. How come can I advocate Rust to serious enterprise customers, if I have to justify using nightlies to make use of such tooling? Apparently downvoting every time someone mentions the issue with nightly being required is fair.
Earlier quoted context omitted.
Author here. AFL is coverage-guided fuzz testing (fuzz testing that relies on code coverage). Someone (not me) wrote an "LLVM pass" that loops through the generated LLVM IR for any LLVM-compiled program and injects the necessary AFL instrumentation such that AFL can work on it: https://github.com/mirrorer/afl/blob/master/llvm_mode/afl-ll... Since Rust uses LLVM when compiling a binary, all afl.rs does is incorporate…
Not sure about this, but isn't this something that could be integrated into rustc (or cargo at least) to be something ready to use as bench/test?
#[fuzz]
fn test_fuzz(bytes: Vec) {
...
}
https://github.com/frewsxcv/afl.rs/issues/24 https://github.com/frewsxcv/afl.rs/issues/31 https://github.com/frewsxcv/afl.rs/pull/46
There's still a little more work to do though. Mainly, I want to compile AFL as a part of the workflow (see the afl-sys crate in the repo) so the user doesn't need to manually install AFL to use `cargo fuzz`.
Earlier quoted context omitted.
> Every time someone posts a cool Rust library, most of the time it makes use of nightly. Examples? Examples that aren't tools, that is. The main example I can think of is serde, and that works on stable (just works better on nightly). What's wrong with nightly for using tooling? You don't have to keep updating, you can pin to a nightly from a particular date. You can use rustup.rs to switch to stable locally if you…
Many companies let their IT control what toolchains one is allowed to use. Usually it is set in stone and only updated every few IT upgrade cycles. What the devs get on their machines is that and nothing more.