AlchemyVM
AlchemyVM copied to clipboard
alexdovzhanyn
Allow custom sections with a name other than `name`
I've got a custom section in my wasm module that has a name jwt. When I attempt to load this module, I get an error. It appears from the code that your parser will throw an exception upon encountering any custom section other than name. This, I believe, breaks the spec rules allowing anyone to embed any custom section with any name. Can we just get the section added to the module as a binary blob if you don't know how to parse it? Then I can turn it into a string and do the decoding myself later.
This is the error I get:
08:40:34.286 [error] Task #PID<0.403.0> started from #PID<0.398.0> terminating
** (RuntimeError) Parser for custom section jwt not implemented
(alchemy_vm) lib/decoding/custom_section_parser.ex:20: AlchemyVM.Decoder.CustomSectionParser.parse_section/2
(alchemy_vm) lib/decoding/custom_section_parser.ex:12: AlchemyVM.Decoder.CustomSectionParser.parse/1
(elixir) lib/task/supervised.ex:90: Task.Supervised.invoke_mfa/2
(elixir) lib/task/supervised.ex:35: Task.Supervised.reply/5
(stdlib) proc_lib.erl:249: :proc_lib.init_p_do_apply/3
Function: &:erlang.apply/2
Args: [#Function<0.83825848/1 in AlchemyVM.Decoder.parallel_decode/1>, [{0, <<3, 106, 119, 116, 101, 121, 74, 48, 101, 88, 65, 105, 79, 105, 74, 113, 100, 51, 81, 105, 76, 67, 74, 104, 98, 71, 99, 105, 79, 105, 74, 108, 90, 68, 73, 49, 78, 84, 69, 53, 73, 110, 48, 46, 101, ...>>}]]
** (EXIT from #PID<0.398.0>) shell process exited with reason: an exception was raised:
** (RuntimeError) Parser for custom section jwt not implemented
(alchemy_vm) lib/decoding/custom_section_parser.ex:20: AlchemyVM.Decoder.CustomSectionParser.parse_section/2
(alchemy_vm) lib/decoding/custom_section_parser.ex:12: AlchemyVM.Decoder.CustomSectionParser.parse/1
(elixir) lib/task/supervised.ex:90: Task.Supervised.invoke_mfa/2
(elixir) lib/task/supervised.ex:35: Task.Supervised.reply/5
(stdlib) proc_lib.erl:249: :proc_lib.init_p_do_apply/3
On this line .. is there a way to just leave the raw binary sitting in the section and not raise an exception? Then my code can just go through the custom section map later, extract the binary, and do what I need with it.
Yeah this is something we haven't implemented yet. I'll look into implementing this weekend -- could you provide some description of how non-name custom sections are typically parsed by other VMs? Or a link to relevant information would be helpful as well.
On Thu, May 2, 2019, 8:48 AM Kevin Hoffman [email protected] wrote:
On this line https://github.com/ElixiumNetwork/AlchemyVM/blob/7a313825ed50720256dda6e61e83356621357963/lib/decoding/custom_section_parser.ex#L20 .. is there a way to just leave the raw binary sitting in the section and not raise an exception? Then my code can just go through the custom section map later, extract the binary, and do what I need with it.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ElixiumNetwork/AlchemyVM/issues/36#issuecomment-488659017, or mute the thread https://github.com/notifications/unsubscribe-auth/ACG5XYQORCWUDCBPNX6UOVDPTLPIPANCNFSM4HJ6AEIA .
According to the spec, the custom sections are designed for debugging or third party use. As such, interpreters typically ignore them (like Rust's wasmer and Firefox and Chrome... all ignore the custom sections). Libraries that allow for reading of module data, like yours and the one Parity has for Rust, should expose access to the custom section "as an uninterpreted sequence of bytes for custom use".
So, with parity-wasm, I can iterate through the custom sections and get a byte array/blob for each one - the main parser doesn't care what the bytes are, it just makes them available to me.
Tangentially related - @alexdovzhanyn are there any benchmarks in terms of execution time and instantiation/load time that I can see? I want to compare them against wasmer
So, with
parity-wasm, I can iterate through the custom sections and get a byte array/blob for each one - the main parser doesn't care what the bytes are, it just makes them available to me.
This makes sense -- we can implement this way since its considered to be the standard approach.
Tangentially related - @alexdovzhanyn are there any benchmarks in terms of execution time and instantiation/load time that I can see? I want to compare them against
wasmer
We don't have any benchmarks at the moment but I expect that in single threaded execution (i.e. one vm instance at a time) Alchemy will be less performant than something written in a lower level language like Rust or C. The goal with alchemy is to be performant when running multiple VMs in parallel. That being said, it should be quite usable for things that don't require a very high throughput.
Did this ever get implemented? I'm curious if this project is still being maintained @alexdovzhanyn