Add rust binding client by CaptainVincent · Pull Request #527 · ipsilon/evmc

CaptainVincent · 2020-06-26T07:16:55Z

Part of #476.

Add rust client binding base on EVMC 7.4.0.
~~f8466c7 is a temporary workaround for evmc_host_context cannot be instantiated.~~ cherry-pick b0c40df from rust: turn evmc_host_context into a void type #524
Update all files' license to Apache 2.0.

I am not yet add any unit test for this module ~~but it work fine with Hera.~~
~~https://github.com/second-state/rust-ssvm/tree/upgrade-evmc-client~~
~~Use this branch follow original example section.~~
~~(I add hera as submodule, replace build.rs to build and link libhera.so and update dummy host function in example)~~
but it already applied on https://github.com/second-state/rust-ssvm/tree/evmc-7 could run example with SSVM.

CaptainVincent · 2020-06-26T07:59:36Z

I saw some ci issues come from my evmc_host_context workaround as below.

/home/circleci/project/include/evmc/evmc.h:164:8: error: struct has no members [-Werror=pedantic]
error: empty struct is a GNU extension [-Werror,-Wgnu-empty-struct]

struct evmc_host_context {};

Code format

-struct evmc_host_context {};
+struct evmc_host_context
+{
+};

bindings-go-latest fail reason unknown.

I think I need some suggestions for pass these tests. Thanks.

axic · 2020-06-26T11:09:50Z

bindings/rust/evmc-client/src/types.rs

+pub type CallKind = ffi::evmc_call_kind;
+pub type Revision = ffi::evmc_revision;
+pub type StatusCode = ffi::evmc_status_code;
+pub type Capabilities = ffi::evmc_capabilities;


Why not use evmc-vm::types instead of duplicating? We could later refactor to pull them out somewhere.

Yes, there is needless. I don't notice main line is already added alias types after I fork it.
Fixed in f726610

axic · 2020-06-26T11:10:37Z

bindings/rust/evmc-client/src/host.rs

+    host_interface: ::std::option::Option<Box<dyn HostInterface>>,
+}
+
+static mut CALLBACK: Callback = Callback {


This makes this not thread-safe. Why did you choose to use this and not use evmc_host_context, which by design is there to avoid having these globals.

Yes, you are right. The original implementation was limited by how much I familiar with Rust. I have rewritten it more like go-binding implementation in 5b2cc1a.

axic · 2020-06-26T11:11:08Z

bindings/rust/evmc-client/src/lib.rs

+        value: &Bytes32,
+        code: &Bytes,
+        create2_salt: &Bytes32,
+    ) -> (&Bytes, i64, StatusCode) {


It would be nice to use evmc-vm::ExecutionResult here.

The struct is incompatible with my idea. I try to hide ffi layer's nest struct to user make it more user friendly.
ex. in bindings.rs

pub struct evmc_address { #[doc = " The 20 bytes of the hash."] pub bytes: [u8; 20usize], }

evmc-vm expose those nest structures directly like Address, Bytes32 ...etc and ExecutionResult include one Address field.
But I usually prefer use the simply types that re-defined in emc-client as below.

pub const ADDRESS_LENGTH: usize = 20; pub const BYTES32_LENGTH: usize = 32; pub type Address = [u8; ADDRESS_LENGTH]; pub type Bytes32 = [u8; BYTES32_LENGTH];

I need confirm which way is better.

Sorry for the delay, but evmc-vm::ExecutionResult is not ffi, it has high-level types.

Also regarding the type aliases, the goal was to eventually replace them with nicer types, but to do it incrementally.

axic · 2020-06-26T11:11:28Z

bindings/rust/evmc-client/src/loader.rs

+    EvmcLoaderInvalidOptionValue = 7,
+}
+
+pub fn evmc_load_and_create(fname: &str) -> (*mut ffi::evmc_vm, EvmcLoaderErrorCode) {


Why did you chose to reimplement this in Rust and not just use the C loader which already exists?

I reimplement it is because I use this function (loader) outside evmc module at first. I want to avoid move partial evmc's C code to my codebase. But I agree it's better and more consistent to use the C loader after I move my evmc relative code into evmc-client now. I will try to replace it use the C loader, but maybe this won't finish too soon.

Finish 5b2b4f2, btw I need cmake in ci environment.

axic · 2020-06-26T11:11:58Z

bindings/rust/evmc-client/src/lib.rs

+use std::ffi::CStr;
+
+extern "C" {
+    fn evmc_create() -> *mut ffi::evmc_vm;


I think as a first step it would be better to only support dynamic loading.

Are you using this static linking in SSVM?

I am not sure this is relative with static linking. I still use dynamic link to lib.so and the statement just tell rustc how to resolve symbol after cargo link the library.
https://github.com/second-state/rust-ssvm/blob/master/build.rs#L25
This is useful in my case that I don't need to know where is my evmc dynamic-link library (especially the target path is not always the same).

If it does an extern import of evmc_create that is statically linking against an EVMC VM, IIRC, otherwise this would be a lingering reference.

Turn evmc_host_context instantiable.

1. remove duplicate types 2. add an alias type Capabilities in evmc-vm

Refine this module make it more like geth client binding implementation.

1. A global static variable requires static lifetime. 2. Box with a trait object requires static lifetime. Avoid host context contain a outside variable with conflict lifetime issue. # Conflicts: # bindings/rust/evmc-client/src/host.rs # bindings/rust/evmc-client/src/lib.rs

axic · 2020-10-09T19:46:10Z

bindings/rust/evmc-client/src/host.rs

+) -> ffi::evmc_result {
+    let msg = *msg;
+    let (output, gas_left, create_address, status_code) =
+        (*(context as *mut ExtendedContext)).hctx.call(


This entire function could be reduced to hctx.call().into() is using ExecutionResult from evmc-vm/lib.rs because that implements the translation and memory handling already.

CaptainVincent force-pushed the rust-binding-client branch 2 times, most recently from 8a81f02 to b87db19 Compare June 26, 2020 07:26

CaptainVincent mentioned this pull request Jun 26, 2020

rust: turn evmc_host_context into a void type #524

Merged

axic reviewed Jun 26, 2020

View reviewed changes

CaptainVincent requested a review from axic July 4, 2020 06:36

CaptainVincent force-pushed the rust-binding-client branch from 5e150ea to 71d3f22 Compare July 17, 2020 01:35

CaptainVincent added 5 commits July 20, 2020 15:25

rust: cherry-pick b0c40df

b3d6ab2

Turn evmc_host_context instantiable.

rust: add evmc client binding

20285d3

license: consistent with official used

e35812f

rust: reorganize alias types

f726610

1. remove duplicate types 2. add an alias type Capabilities in evmc-vm

rust: make evmc-client thread safety with HostContext

5b2cc1a

Refine this module make it more like geth client binding implementation.

CaptainVincent force-pushed the rust-binding-client branch from 71d3f22 to 3f9eb21 Compare July 20, 2020 08:49

rust: use evmc c loader replace pure rust version

5b2b4f2

CaptainVincent force-pushed the rust-binding-client branch from 3f9eb21 to 5b2b4f2 Compare July 20, 2020 09:05

CaptainVincent added 2 commits July 30, 2020 07:47

rust: call add salt supported

e54e3e5

axic reviewed Oct 9, 2020

View reviewed changes

rust: use git clone evmc source before build and link loader

e5e955a

axic mentioned this pull request May 6, 2022

rust: add evmc-client binding #640

Draft

Conversation

CaptainVincent commented Jun 26, 2020 • edited by axic Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

CaptainVincent commented Jun 26, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

CaptainVincent Jun 29, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

CaptainVincent Jun 29, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

CaptainVincent commented Jun 26, 2020 •

edited by axic

Loading

CaptainVincent commented Jun 26, 2020 •

edited

Loading

CaptainVincent Jun 29, 2020 •

edited

Loading

CaptainVincent Jun 29, 2020 •

edited

Loading