-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
utils: add signature to WasmEngine::find_function #331
Conversation
test/bench/bench.cpp
Outdated
std::cout << l << std::endl; | ||
if (l.find_first_of(":") != l.find_last_of(":")) | ||
throw std::runtime_error{"Multiple occurances of ':' found in signature"}; | ||
// Only allow i (i32) I (i64) v (void) as types |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to decide on a design here, the main question is about return types and no arguments cases:
a) Require colon and void type, e.g. i:v
, i:i
b) Allow empty return type, no need for void, e.g. i:
c) Omit colon if no return type, e.g. i
d) Require void on input side if there no inputs, but there's an output, e.g. v:i
e) Allow empty arguments, e.g. :i
I'm not sure what is the best, but leaning towards c) and e).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like a) because everything is explicit and easier to parse
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the case of a), what happens when there are no inputs? :v
and :i
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- If this is based on WAMR I would use what they have.
- I would not use
v
at all to be consistent with wasm types, where it is[]
. - I would keep
:
always for parsing. So:
is also valid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not based on WAMR. Mentioned it here before: #318 (comment)
- wasm3 uses a version of this, but has a reverse notation where return value is first (e.g.
v(ii)
) - emscripten uses a version of this: it has no separation of input vs output (e.g.
iiv
), but rather assumes the last type is either a type or void - wamr uses a version of this, but unclear what they do for the return value
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chfast are you saying these rules then:
:
no input, no outputi:
single i32 input, no output:i
single i32 output, no input- etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. But if this is something different than anything else, I don't care so much.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may want to improve/change/use it later on in the external API, then we can come back. All we need right now is just to make the benchmark tool more convenient to use, to support wamr, and to make fizzy-wasi nicer. Any of the solutions accomplish that, but prefer to take the easiest-to-parse route than anything else now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the case of a), what happens when there are no inputs? :v and :i ?
v:v
, v:i
I guess it's d) or a) + d)
st = InputsReadingState::FuncSignature; | ||
break; | ||
|
||
case InputsReadingState::FuncSignature: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chfast suggested to conflate the signature into the name line, such as keccak256_bnech iii:i
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be nicer for reading input files, but I don't insist.
test/utils/fizzy_engine.cpp
Outdated
{ | ||
return fizzy::find_exported_function(m_instance->module, name); | ||
bool matching_signature(const fizzy::FuncType& func_type, std::string_view signature) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably would be nicer to have simple translator instead (sig -> func_type) and equal operator for func_type
. Update: we actually already have the equal operator.
test/utils/wasm_engine.hpp
Outdated
@@ -55,6 +56,17 @@ class WasmEngine | |||
/// Executes the function of the given index. | |||
/// Requires instantiate(). | |||
virtual Result execute(FuncRef func_ref, const std::vector<uint64_t>& args) = 0; | |||
|
|||
static void validate_function_signature(std::string_view signature) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer to make it a free function in fizzy::test
, but not so important
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would that mean to make inline in the header or creating yet another file, wasm_engine.cpp
, to place it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chfast any preference?
a) as it is now
b) as a free function in the header
c) as a free function in a new .cpp
file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For sanity, it is preferable to move implementation to .cpp file.
For static method / free function I think both options are fine.
Do you plan to add this validation to all of the engines? |
Initially I thought so, but I think it is fine to only do it in fizzy (it detects problems in all our test cases) and only do the conversion for a given engine when there's need (such as wamr would depend on it for implementation). |
099da55
to
abee111
Compare
Codecov Report
@@ Coverage Diff @@
## master #331 +/- ##
==========================================
- Coverage 98.86% 98.85% -0.01%
==========================================
Files 40 41 +1
Lines 11779 11854 +75
==========================================
+ Hits 11645 11718 +73
- Misses 134 136 +2 |
3d7c85f
to
1739212
Compare
Squashed this down quite a bit. |
@@ -37,7 +37,8 @@ class WasmEngine | |||
|
|||
/// Finds an exported function in the internal instance. | |||
/// Requires instantiate(). | |||
virtual std::optional<FuncRef> find_function(std::string_view name) const = 0; | |||
virtual std::optional<FuncRef> find_function( | |||
std::string_view name, std::string_view signature) const = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be signature
or sig
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
signature
.
test/utils/wasm_engine.cpp
Outdated
@@ -0,0 +1,20 @@ | |||
// Fizzy: A fast WebAssembly interpreter | |||
// Copyright 2019-2020 The Fizzy Authors. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// Copyright 2019-2020 The Fizzy Authors. | |
// Copyright 2020 The Fizzy Authors. |
Also introduce validate_function_signature helper.
And validate its format.
This is required for wamr support. Also it can help us avoid mistakes if we validate signatures in the engines.
Should also add signature type validation to
find_function
. That helps with both this PR and #329.