afonso360 opened issue #5815:
:wave: Hey
Feature
Our
cranelift-fuzzgen
fuzzer currently always uses thesystem_v
calling convention on all functions.We should change this so that we can explore other calling conventions!
Benefit
This increases coverage for the cranelift fuzzers. The cranelift fuzzer can reach a bit further into the ABI code since it generates a broader number of types (i.e. I8/I16/I128).
Implementation
We now have a
Target
in theFunctionGenerator
so we can make decisions based on that.We have a number of calling conventions that are applicable to all
Targets
such asSystemV
/Cold
/Fast
, those are always available to be selected. But there are some that should be somewhat restricted such asAppleAarch64
which we should only select onaarch64
andmacosx
.Alternatives
Some of these calling conventions are already fuzzed via the wasmtime fuzzers, so we could keep relying on that.
afonso360 labeled issue #5815:
:wave: Hey
Feature
Our
cranelift-fuzzgen
fuzzer currently always uses thesystem_v
calling convention on all functions.We should change this so that we can explore other calling conventions!
Benefit
This increases coverage for the cranelift fuzzers. The cranelift fuzzer can reach a bit further into the ABI code since it generates a broader number of types (i.e. I8/I16/I128).
Implementation
We now have a
Target
in theFunctionGenerator
so we can make decisions based on that.We have a number of calling conventions that are applicable to all
Targets
such asSystemV
/Cold
/Fast
, those are always available to be selected. But there are some that should be somewhat restricted such asAppleAarch64
which we should only select onaarch64
andmacosx
.Alternatives
Some of these calling conventions are already fuzzed via the wasmtime fuzzers, so we could keep relying on that.
afonso360 labeled issue #5815:
:wave: Hey
Feature
Our
cranelift-fuzzgen
fuzzer currently always uses thesystem_v
calling convention on all functions.We should change this so that we can explore other calling conventions!
Benefit
This increases coverage for the cranelift fuzzers. The cranelift fuzzer can reach a bit further into the ABI code since it generates a broader number of types (i.e. I8/I16/I128).
Implementation
We now have a
Target
in theFunctionGenerator
so we can make decisions based on that.We have a number of calling conventions that are applicable to all
Targets
such asSystemV
/Cold
/Fast
, those are always available to be selected. But there are some that should be somewhat restricted such asAppleAarch64
which we should only select onaarch64
andmacosx
.Alternatives
Some of these calling conventions are already fuzzed via the wasmtime fuzzers, so we could keep relying on that.
afonso360 edited issue #5815:
:wave: Hey
Feature
Our
cranelift-fuzzgen
fuzzer currently always uses thesystem_v
calling convention on all functions.We should change this so that we can explore other calling conventions!
Benefit
This increases coverage for the cranelift fuzzers. The cranelift fuzzer can reach a bit further into the ABI code since it generates a broader number of types (i.e. I8/I16/I128).
Implementation
We now have a
Target
in theFunctionGenerator
so we can make decisions based on that.We have a number of calling conventions that are applicable to all
Targets
such asSystemV
/Cold
/Fast
, those are always available to be selected. But there are some that should be somewhat restricted such asAppleAarch64
which we should only select onaarch64
andmacosx
.If anyone would like to take this on and needs some further help/clarification let me know!
Alternatives
Some of these calling conventions are already fuzzed via the wasmtime fuzzers, so we could keep relying on that.
jameysharp labeled issue #5815:
:wave: Hey
Feature
Our
cranelift-fuzzgen
fuzzer currently always uses thesystem_v
calling convention on all functions.We should change this so that we can explore other calling conventions!
Benefit
This increases coverage for the cranelift fuzzers. The cranelift fuzzer can reach a bit further into the ABI code since it generates a broader number of types (i.e. I8/I16/I128).
Implementation
We now have a
Target
in theFunctionGenerator
so we can make decisions based on that.We have a number of calling conventions that are applicable to all
Targets
such asSystemV
/Cold
/Fast
, those are always available to be selected. But there are some that should be somewhat restricted such asAppleAarch64
which we should only select onaarch64
andmacosx
.If anyone would like to take this on and needs some further help/clarification let me know!
Alternatives
Some of these calling conventions are already fuzzed via the wasmtime fuzzers, so we could keep relying on that.
littlebenlittle commented on issue #5815:
Started a PR for this. Are there any calling conventions other than
AppleAarch64
that should be contextually supported based on target triple?Also I'm not sure if generators should be zero-allocation for efficiency.
jameysharp commented on issue #5815:
I think this might have actually been fixed already, by #6579, which just merged a couple of days ago.
I'm a little confused about the state of this issue though. There are two places we pick calling conventions in fuzzgen right now. #6579 only changed one of them, and your PR #6594 changes the other. But I think maybe we can't actually change the latter place without breaking things.
Specifically, your PR extends
FunctionGenerator::system_callconv
, which is only used to decide how to call libcalls. If I'm not mistaken, these libcalls are provided by libc, so they use the system's native C calling convention. If I have that right then we only have one choice for calling convention there, but that choice depends on the target OS.@afonso360, could you clarify whether there's more to do in this issue or whether it should be closed?
afonso360 commented on issue #5815:
Oh, I forgot to close this issue, I'm sorry!
Yeah, that's pretty much right, we have to choose the right calling convention according to the platform we are currently executing. I think
cargo-fuzz
supports MacOS, however I'm not sure anyone is currently running it there, so we haven't had the need to add any other system calling conventions.I don't think there is anything else missing here, but thanks for looking into this @littlebenlittle!
afonso360 closed issue #5815:
:wave: Hey
Feature
Our
cranelift-fuzzgen
fuzzer currently always uses thesystem_v
calling convention on all functions.We should change this so that we can explore other calling conventions!
Benefit
This increases coverage for the cranelift fuzzers. The cranelift fuzzer can reach a bit further into the ABI code since it generates a broader number of types (i.e. I8/I16/I128).
Implementation
We now have a
Target
in theFunctionGenerator
so we can make decisions based on that.We have a number of calling conventions that are applicable to all
Targets
such asSystemV
/Cold
/Fast
, those are always available to be selected. But there are some that should be somewhat restricted such asAppleAarch64
which we should only select onaarch64
andmacosx
.If anyone would like to take this on and needs some further help/clarification let me know!
Alternatives
Some of these calling conventions are already fuzzed via the wasmtime fuzzers, so we could keep relying on that.
Last updated: Dec 23 2024 at 13:07 UTC