EVM-C: Remove factory class #131

chfast · 2017-09-22T17:36:33Z

This is final change to EVM-C API +/- documentation fixes and small refactorings.

I reviewed the previous version by drawing the class diagram of it. I managed to reduce it from 4 classes: Host, Context, EVM, Factory to only 2: EVM and Context. Now it matches very simple OOP polymorphic desing, but it is hard to see in under big C overhead.

I'm not sure we should keep the ABI_VERSION field. It does not seem to be useful in near future.

The still missing piece is tracing.

gcolvin · 2017-10-01T02:23:42Z

@chfast After reading through the code I decided to build the library from the readme instructions. That seemed to go fine until I got to step 5. It doesn't say what directory the build directory should go in, and searching my hard drive for CMakeLists.txt didn't find anyplace that looked right.

Install llvm-3.7-dev package
For Ubuntu 14.04 using LLVM deb packages source: http://llvm.org/apt
For Ubuntu 14.10 using Ubuntu packages
Build library with cmake
mkdir build && cd $_
cmake .. && make
Install library
sudo make install
sudo ldconfig

gcolvin

Very nice!

gcolvin · 2017-10-01T02:39:18Z

include/evm.h

-    /// FIXME: We should rethink reporting internal errors. One of the options
-    /// it to allow using any negative value to represent internal errors.
+    /// @todo We should rethink reporting internal errors. One of the options
+    ///       it to allow using any negative value to represent internal errors.
    EVM_INTERNAL_ERROR = -1,


Handing over all the negative numbers seems a good idea. An optional string might be good if the memory management isn't too much trouble.

Ok, I will clarify that negative values are allowed and are related to implementation-defined errors.

Yes, additional error message is possible. We actually had it in evm_result before, but it was removed. Memory management is not a problem, because evm_result have "virtual destruktor". However, I'd like to add it the moment we have any practical use case for it. What do you think @axic? Do you need it in your eWASM enabled fork of cpp-ethereum?

gcolvin · 2017-10-01T03:39:21Z

include/evm.h

 ///
 /// @return  EVM instance.
-struct evm_factory examplevm_get_factory(void);
+/// @todo Specify if this function can return null pointer to indicate error.
+struct evm_instance* examplevm_create(void);



I think it has to be able to return a null.

gcolvin · 2017-10-01T05:19:16Z

include/evm.h

@@ -437,6 +428,15 @@ typedef void (*evm_prepare_code_fn)(struct evm_instance* instance,
 ///


So CACHED code doesn't have to be on-disk, but won't become UNKNOWN? And READY code might become CACHED, or might go back to being UNKNOWN?

I probably missed it, but what are the flags? Implementation defined? They show up in few places.

It might be good to allow for implementations that support preparation to execute ready or cached code based on the code's hash.

I needed this to have the same capabilities in API for JIT as before going EVM-C. This is needed for SmartJIT strategy - it has to decide where to delegate the execution - to JIT or to interpreter.

READY means the pre-processed code is in memory and there is not overhead of starting execution in JIT.
CACHED means the pre-processed code is on-disk and the overhead of executing in JIT will be to load the code from disk.

We should think about generalizing this API more... but it is not critical at the moment, and not required to implement interpreter.

Thanks, but I'm still confused. Let me try again.

Are READY files guaranteed to be ready for subsequent calls?

Are CACHED files guaranteed to be cached or ready for subsequent calls?
This matters for a JIT, as I understand that a JIT that does not cache its output and keep it cached can be exploited.
(Whether the cache is on disk or in memory is an implementation detail.)

No and no.
In terms of JIT, READY means that the code is in memory. Memory is limited, you have to delete some codes over time.
The same for CACHED. Your disk space is limited, so you may want to remove some codes from on-disk cache.
So there are no guarantees that any code will preserve its current status.

OK. The first no I expected. But I do worry about code falling out of the cache. In discussions with @Arachnid he was quite clear that caches that can spill are exploitable. I'll hope he shows up and explains.

Yes - any cache with eviction cannot be relied on as a performance optimisation in a blockchain environment. The attacker can simply devise an attack that round-robins a larger number of entries than the cache can hold, guaranteeing every single action is a cache miss.

Thanks to explaining this to me. Then, the CACHED code SHOULD be maintained the same way the Ethereum state is. I will add this clarification in comments.

And as I think we discussed, a good strategy might be to compile and cache contracts when they are first created so an interpreter isn't even needed.

chfast

Sorry about build instructions. They are always out-dated.

Anyway, If you want to play with EVM-C you only need the header evm.h.

chfast · 2017-10-02T09:29:12Z

include/evm.h

-    /// FIXME: We should rethink reporting internal errors. One of the options
-    /// it to allow using any negative value to represent internal errors.
+    /// @todo We should rethink reporting internal errors. One of the options
+    ///       it to allow using any negative value to represent internal errors.
    EVM_INTERNAL_ERROR = -1,


Ok, I will clarify that negative values are allowed and are related to implementation-defined errors.

Yes, additional error message is possible. We actually had it in evm_result before, but it was removed. Memory management is not a problem, because evm_result have "virtual destruktor". However, I'd like to add it the moment we have any practical use case for it. What do you think @axic? Do you need it in your eWASM enabled fork of cpp-ethereum?

chfast · 2017-10-02T09:39:48Z

include/evm.h

@@ -437,6 +428,15 @@ typedef void (*evm_prepare_code_fn)(struct evm_instance* instance,
 ///


I needed this to have the same capabilities in API for JIT as before going EVM-C. This is needed for SmartJIT strategy - it has to decide where to delegate the execution - to JIT or to interpreter.

READY means the pre-processed code is in memory and there is not overhead of starting execution in JIT.
CACHED means the pre-processed code is on-disk and the overhead of executing in JIT will be to load the code from disk.

We should think about generalizing this API more... but it is not critical at the moment, and not required to implement interpreter.

chfast · 2017-10-02T09:40:01Z

include/evm.h

 ///
 /// @return  EVM instance.
-struct evm_factory examplevm_get_factory(void);
+/// @todo Specify if this function can return null pointer to indicate error.
+struct evm_instance* examplevm_create(void);



chfast added 2 commits September 22, 2017 18:50

EVM-C: Move ABI version from factory to instance

ac1a4c7

EVM-C: Remove factory

d639b5b

chfast requested review from axic and gcolvin September 22, 2017 17:36

chfast force-pushed the evmc-no-factory branch from 218d986 to 79663b4 Compare September 23, 2017 11:38

EVM-C: Rename evm_result_code -> evm_status_code

fe81570

chfast force-pushed the evmc-no-factory branch from 79663b4 to a3cce32 Compare September 26, 2017 12:13

chfast added 2 commits September 26, 2017 16:51

EVM-C: Rename evm_result::code -> evm_result::status_code

c039851

EVM-C: Rename evm_uint160be -> evm_address

c7a351c

chfast force-pushed the evmc-no-factory branch from a3cce32 to c7a351c Compare September 26, 2017 14:51

gcolvin approved these changes Oct 1, 2017

View reviewed changes

chfast commented Oct 2, 2017

View reviewed changes

EVM-C: Allow returning NULL from create() functions

4a28be0

chfast merged commit 2490f6d into develop Oct 2, 2017

chfast deleted the evmc-no-factory branch October 2, 2017 16:03

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

EVM-C: Remove factory class #131

EVM-C: Remove factory class #131

chfast commented Sep 22, 2017

gcolvin commented Oct 1, 2017

gcolvin left a comment

gcolvin Oct 1, 2017

chfast Oct 2, 2017

gcolvin Oct 1, 2017

chfast Oct 2, 2017

gcolvin Oct 1, 2017

chfast Oct 2, 2017

gcolvin Oct 2, 2017

chfast Oct 2, 2017

gcolvin Oct 2, 2017

Arachnid Oct 3, 2017

chfast Oct 3, 2017

gcolvin Oct 3, 2017

chfast left a comment

chfast Oct 2, 2017

chfast Oct 2, 2017

chfast Oct 2, 2017

		@@ -437,6 +428,15 @@ typedef void (evm_prepare_code_fn)(struct evm_instance instance,
		///

EVM-C: Remove factory class #131

EVM-C: Remove factory class #131

Conversation

chfast commented Sep 22, 2017

gcolvin commented Oct 1, 2017

gcolvin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chfast left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment