Tracing API #32

chfast · 2018-05-11T12:54:34Z

Fixes #22.

axic

Has a serious lack of comments :)

axic · 2018-05-15T16:24:30Z

include/evmc/evmc.h

+                                    size_t code_offset,
+                                    enum evmc_status_code status_code,
+                                    int64_t gas_left,
+                                    const struct evmc_uint256be* top_stack_item,


Shouldn't this have a stack count? Does depth above mean stack height or call depth?

axic · 2018-05-15T16:24:41Z

include/evmc/evmc.h

+
+typedef void (*evmc_trace_callback)(struct evmc_tracer_context* context,
+                                    int depth,
+                                    int step,


Should this be called pc?

axic · 2018-05-15T16:24:56Z

include/evmc/evmc.h

+typedef void (*evmc_trace_callback)(struct evmc_tracer_context* context,
+                                    int depth,
+                                    int step,
+                                    size_t code_offset,


Is this pc?

The problem with "pc" name I have is not everyone knows exactly that it is exactly. I think code_offest === pc.

So what is code_offset and what is step ?

The step is the number of executed instructions so far (only increases).
The code_offset is the position in the code where we are currently. It's different than the step because of jump and push instructions.

execution_step perhaps? Not sure, step, without any documentation gave me the wrong indication about what it is.

Why don't you want to have a documentation above it?

We can also remove this because this can be implemented easily on the client side.

I will add documentation soon. I just need to finish other PRs first.

chfast · 2018-05-15T16:27:37Z

Has a serious lack of comments :)

Intentionally. I expect this to change a lot in the first phase. And I want this to be clear enough without comments.

gumb0 · 2018-06-07T12:05:04Z

include/evmc/evmc.h

+                                    size_t changed_memory_size,
+                                    const uint8_t* changed_memory);
+
+typedef void (*evmc_set_tracer)(struct evmc_instance* instance,


Shouldn't this return a pointer to previously set callback?
Why do you need to declare a pointer to function (evmc_set_tracer) if it's just to declare one function?

Yes, it can return previous callback, but it would be hard to also return the context, so you will not be able to restore previous state anyway.

(If I understand the question) The evmc_instance is a set of function pointers. It is easier to read the spec when function pointer types are declared separately. I forgot the _fn suffix in this type name.

Ah ok, I didn't notice that it's a part of evmc_instance, sorry

chfast · 2018-06-18T12:24:43Z

Documentation added.
Depth param removed. This can be taken easily from the message.
@cdetrio, @ehildenb can you check English in docs?

chfast · 2018-06-18T12:28:02Z

The PoC is here: ethereum/aleth#5065

I believe the API is good enough to be merged as is. That would allow me to focus on geth support for EVMC.

gumb0 · 2018-06-18T16:47:48Z

include/evmc/evmc.h

+ * @param context                The pointer to the Client-side tracing context. This allows to
+ *                               implement the tracer in OOP manner.
+ * @param step                   The instruction counter for the current message.
+ * @param code_offset            The instruction possition in the code.


typo: position

gumb0 · 2018-06-18T17:00:55Z

include/evmc/evmc.h

+ *
+ * @param context                The pointer to the Client-side tracing context. This allows to
+ *                               implement the tracer in OOP manner.
+ * @param step                   The instruction counter for the current message.


Maybe to clarify it instead of "current message" call it " The instruction counter after the instruction execution."
And also below add "after the instruction execution" for code_offset, stack_num_items, memory_size

chfast · 2018-06-19T08:16:55Z

I changed the documentation.

axic · 2018-06-19T22:54:15Z

include/evmc/evmc.h

+ * The callback to trace instructions execution in an EVM.
+ *
+ * This function informs the Client what instruction has been executed in the EVM implementation
+ * and what are the results of the execution this particular instruction.


execution of this or of executing this

axic · 2018-06-19T22:56:48Z

include/evmc/evmc.h

+ * @param status_code            The status code of the instruction execution.
+ * @param gas_left               The amount of the gas left after the instruction execution.
+ * @param stack_num_items        The current EVM stack height after the instruction execution.
+ * @param pushed_stack_item      The top EVM stack item pushed as the result of the instruction


So based on these two the client needs to apply the stack changes?

Any comments?

If the tracer want to know what's on stack it has to track the changes. This is even more complicated when you consider SWAP and DUP instructions - the tracer would have to reapply SWAP and DUP semantics.

Are we sure there aren't ever going to be instructions pushing more than one item?

In theory we have them now in form of DUP and SWAP.
In practice, not likely needed. We can also change the API in future. I will check WASM instructions.

axic · 2018-06-19T22:57:25Z

include/evmc/evmc.h

+ *                               the instruction execution.
+ * @param changed_memory_size    The size of the memory area modified as the result of
+ *                               the instruction execution.
+ * @param changed_memory         The pointer to the memory area modified as the result of


Why is this needed if one can calculate that via changed_memory_offset?

Any comments?

You cannot calculate it via changed_memory_offset without having the base memory pointer. We can return the base memory pointer instead of the pointer to the changed area. However that would put higher requirements on EVM memory layout.

I think it's probably best (esp for other implementations) to directly pass back the changed memory. Not all language give you access to memory via pointers, so having an explicit argument present here will make it easier to use as a guide for implementing traces in other languages.

My question is how will you handle it if there are multiple disjoint changed regions of memory? What if they are very spaced out (as is often the case when using the "hash of variable name" scheme for deciding where to place things)?

directly pass back the changed memory

I'm not sure what you exactly mean by this.

My question is how will you handle it if there are multiple disjoint changed regions of memory?

You don't. There should be a way to report without information about memory. Something like changed_memory_size == -1. I'm leaving it unanswered because I don't have good solution at the moment. I prefer do defer the decision until we have the use case for it.

axic · 2018-06-19T22:58:54Z

include/evmc/evmc.h

+/**
+ * Sets the EVM instruction tracer.
+ *
+ * When the tracer is set in the EVM instance, the EVM SHOULD callback the tracer with information


callback -> call or call back

axic · 2018-06-19T23:03:05Z

include/evmc/evmc.h

+     *
+     * If the EVM does not support this feature the pointer can be NULL.
+     */
+    evmc_set_tracer_fn set_tracer;


Can this be unset after its being set?

I don't fully remember (and seemingly our documentation isn't clear enough): can an evmc_instance reused for multiple executions?

Good question. Answered in the latest commit.

That commit looks good.

chfast · 2018-06-20T08:45:39Z

I pushed additional commit with improved documentation. I will squeeze them later (easier to review changes now).

chfast · 2018-06-20T12:48:43Z

include/evmc/evmc.h

+ *                               This counter starts from 0 for every message passed to
+ *                               ::evmc_execute_fn.
+ * @param code_offset            The current instruction position in the code.
+ * @param status_code            The status code of the instruction execution.


I'm not sure this is useful (99% of the time the value is 0). And the Client can get it from evm_result in the end.

ehildenb · 2018-06-21T14:32:28Z

include/evmc/evmc.h

+ *                               implement the tracer in OOP manner.
+ * @param step                   The instruction counter: number of instructions executed.
+ *                               This counter starts from 0 for every message passed to
+ *                               ::evmc_execute_fn.


Why call this step instead of the more conventional programCounter? Is this to facilitate ewasm?

See #32 (comment)

This is not the program counter. Program counter points the instruction being executed, so it's code_offset in this case. The step is the trace entry index.

I'm ok with renaming any of those if you have better ideas for names.

How about tracing_step or trace_index ? Why is it needed?

Precisely I wanted the "instruction counter" per current message (i.e. EVM call). This is not not needed (because the Host can count tracing callback calls on its own) UNLESS the VM will not report every instruction.
I propose to rename it to instruction_counter or remove it for now.

I think that's why trace_counter/trace_step/trace_index is the appropriate name.

I'm not sure this is a useful field though.

I mean this case where VM only traces storage instructions:

PUSH 0 SLOAD PUSH 9 SSTORE

When counting the number of traces you should get:

(0, SLOAD, ...) (1, SSTORE, ...)

When counting number of instructions you should get:

(1, SLOAD, ...) (3, SSTORE, ...)

In the second case the Host can figure out that some executed instructions are missing in the trace. In the first case the counter is redundant as the Host can count it itself.

I'm going to remove the param.

I mean this case where VM only traces storage instructions:

You mean a specific VM won't support tracing every instruction?

I have no problem keeping it, but step seems to be rather confusing. Consider some of the suggestions above.

chfast · 2018-06-25T08:36:54Z

@axic @ehildenb Whould you like to re-review this again (including review comments)?

axic · 2018-07-13T14:58:55Z

Rebased.

jwasinger · 2018-07-16T06:21:20Z

examples/examplevm/examplevm.c

@@ -9,6 +9,8 @@ struct examplevm
 {
    struct evmc_instance instance;
    int verbose;
+    evmc_trace_callback trace_callback;


it would be useful to have another callback to allow the EVM to log text back to the client.

instead of a separate callback, actually it could just be added as an additional parameter to evmc_trace_callback.

Okay, EVM can just do this via stderr.

The C++ std::cerr works. We could add a logger method to capture VM logs nicely on the Host side. But that is different feature and should be done independently.

The tracing API has been added.

axic · 2018-07-25T16:29:45Z

include/evmc/evmc.h

+ *                               The pointer MUST NOT be stored by the Client.
+ *                               The Client MUST NOT assume that
+ *                               `changed_memory - changed_memory_offset` is a valid base pointer
+ *                               of the VM memory.


I'm glad we discussed these on Gitter, much more cleaner now.

axic requested changes May 15, 2018

View reviewed changes

axic reviewed May 15, 2018

View reviewed changes

chfast force-pushed the tracing branch from 2b71d4f to 9505981 Compare June 5, 2018 16:20

chfast mentioned this pull request Jun 5, 2018

EVMC tracing for interpreter ethereum/aleth#5065

Open

gumb0 reviewed Jun 7, 2018

View reviewed changes

chfast force-pushed the tracing branch 3 times, most recently from ce65d2d to 99f8c03 Compare June 18, 2018 11:50

chfast requested review from axic and gumb0 June 18, 2018 15:05

gumb0 reviewed Jun 18, 2018

View reviewed changes

axic reviewed Jun 19, 2018

View reviewed changes

chfast force-pushed the tracing branch from 0a6a0c7 to 535ffea Compare June 20, 2018 10:07

chfast commented Jun 20, 2018

View reviewed changes

gumb0 approved these changes Jun 21, 2018

View reviewed changes

ehildenb reviewed Jun 21, 2018

View reviewed changes

axic force-pushed the tracing branch from 535ffea to dcd9a3e Compare July 13, 2018 14:58

jwasinger reviewed Jul 16, 2018

View reviewed changes

chfast force-pushed the tracing branch 2 times, most recently from 95d1f23 to 925b714 Compare July 18, 2018 11:30

axic approved these changes Jul 25, 2018

View reviewed changes

chfast force-pushed the tracing branch from a1ce369 to fcf599a Compare July 25, 2018 16:20

chfast added 9 commits July 25, 2018 18:22

Tracing API

91065ca

CMake: Move evmc-vmtester binary to test/

2c7ad06

Do not allow set_tracer function to be null

d2ac75f

Make tracing feature optional

9e31e93

Improve documentation for EVM tracing

59dc54e

tracing: Remove "steps" parameter

17d95f2

tracing: Clarify documentation of "changed memory"

e93da0e

tracing: Fix test compilation with VS 2015

9bda457

Bump ABI version to 3

a3cb335

The tracing API has been added.

chfast force-pushed the tracing branch from fcf599a to a3cb335 Compare July 25, 2018 16:25

axic reviewed Jul 25, 2018

View reviewed changes

axic merged commit 332d035 into master Jul 25, 2018

axic deleted the tracing branch July 25, 2018 17:00

Tracing API #32

Tracing API #32

Conversation

chfast commented May 11, 2018 • edited by axic

axic 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

chfast commented May 15, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chfast commented Jun 18, 2018

chfast commented Jun 18, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chfast commented Jun 19, 2018

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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chfast commented Jun 20, 2018

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 commented Jun 25, 2018

axic commented Jul 13, 2018

jwasinger Jul 16, 2018 • edited

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 commented May 11, 2018 •

edited by axic

jwasinger Jul 16, 2018 •

edited