Stream: git-wasmtime

Topic: wasmtime / issue #5815 fuzzgen: Fuzz different calling co...

Wasmtime GitHub notifications bot (Feb 17 2023 at 13:11):

afonso360 opened issue #5815:

:wave: Hey

Feature

Our cranelift-fuzzgen fuzzer currently always uses the system_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 the FunctionGenerator so we can make decisions based on that.

We have a number of calling conventions that are applicable to all Targets such as SystemV/Cold/Fast, those are always available to be selected. But there are some that should be somewhat restricted such as AppleAarch64 which we should only select on aarch64 and macosx.

Alternatives

Some of these calling conventions are already fuzzed via the wasmtime fuzzers, so we could keep relying on that.

Wasmtime GitHub notifications bot (Feb 17 2023 at 13:11):

afonso360 labeled issue #5815:

:wave: Hey

Feature

Our cranelift-fuzzgen fuzzer currently always uses the system_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 the FunctionGenerator so we can make decisions based on that.

We have a number of calling conventions that are applicable to all Targets such as SystemV/Cold/Fast, those are always available to be selected. But there are some that should be somewhat restricted such as AppleAarch64 which we should only select on aarch64 and macosx.

Alternatives

Some of these calling conventions are already fuzzed via the wasmtime fuzzers, so we could keep relying on that.

Wasmtime GitHub notifications bot (Feb 17 2023 at 13:11):

afonso360 labeled issue #5815:

:wave: Hey

Feature

Our cranelift-fuzzgen fuzzer currently always uses the system_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 the FunctionGenerator so we can make decisions based on that.

We have a number of calling conventions that are applicable to all Targets such as SystemV/Cold/Fast, those are always available to be selected. But there are some that should be somewhat restricted such as AppleAarch64 which we should only select on aarch64 and macosx.

Alternatives

Some of these calling conventions are already fuzzed via the wasmtime fuzzers, so we could keep relying on that.

Wasmtime GitHub notifications bot (Feb 17 2023 at 13:12):

afonso360 edited issue #5815:

:wave: Hey

Feature

Our cranelift-fuzzgen fuzzer currently always uses the system_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 the FunctionGenerator so we can make decisions based on that.

We have a number of calling conventions that are applicable to all Targets such as SystemV/Cold/Fast, those are always available to be selected. But there are some that should be somewhat restricted such as AppleAarch64 which we should only select on aarch64 and macosx.

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.

Wasmtime GitHub notifications bot (Feb 17 2023 at 20:20):

jameysharp labeled issue #5815:

:wave: Hey

Feature

Our cranelift-fuzzgen fuzzer currently always uses the system_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 the FunctionGenerator so we can make decisions based on that.

We have a number of calling conventions that are applicable to all Targets such as SystemV/Cold/Fast, those are always available to be selected. But there are some that should be somewhat restricted such as AppleAarch64 which we should only select on aarch64 and macosx.

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.

Wasmtime GitHub notifications bot (Jun 16 2023 at 20:35):

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.

Wasmtime GitHub notifications bot (Jun 16 2023 at 23:21):

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?

Wasmtime GitHub notifications bot (Jun 17 2023 at 09:55):

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!

Wasmtime GitHub notifications bot (Jun 17 2023 at 09:55):

afonso360 closed issue #5815:

:wave: Hey

Feature

Our cranelift-fuzzgen fuzzer currently always uses the system_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 the FunctionGenerator so we can make decisions based on that.

We have a number of calling conventions that are applicable to all Targets such as SystemV/Cold/Fast, those are always available to be selected. But there are some that should be somewhat restricted such as AppleAarch64 which we should only select on aarch64 and macosx.

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: Nov 22 2024 at 17:03 UTC