solcasm2 v1.0.3

solcasm (evm-assembler)

This assembler is able to convert the EVM assembly dialect that has been generated by solc into valid EVM bytecode.

Note: This project has been initially forked from RafaelSalguero/evm-assembler at commit 9944664.

Install it

yarn add solcasm2

or

npm i solcasm2

solc --asm compatible assembler

1.- Write EVM assembly in the same format as solc --asm output or convert your Solidity code into this EVM assembly dialect.

  mstore(0x40, 0x80)
  callvalue
  dup1
  iszero
  tag_1
  jumpi
  0x00
  dup1
  revert
tag_1:
  pop
  dataSize(sub_0)
  dup1
  dataOffset(sub_0)
  0x00
  codecopy
  0x00
  return
stop

sub_0: assembly {
      mstore(0x40, 0x80)
}

2.- Compile it

npx solcasm2 contract.evm contract.bin

output:

6080604052348015600f57600080fd5b50600580601d6000396000f3006080604052

Helper Functions

This assembler supports several custom helper functions that are resolved to valid opcodes and thus valid bytecode at compile time. The following chapters explain those utilitiy functions.

Stack Peek (stack_peek_1 to stack_peek_12)

The stack_peek_* helper functions can be used to inspect the stack during execution. The function will write the stack element at the specfied stack position to the log. Speeking in Solidity, this is similar to emitting the following event: Stackpeek(uint256 pos, bytes32 data). Since this also writes to memory, it might overwrite data in memory that has already been stored there from previous steps, leading to an error in the following executions. Thus, it is recommended to add a stop after calling stack_peek_* or serveral stack_peek_* commands to halt the execution after the stack was inspected. Since this function was designed for debugging sessions, stopping after logging the stack should not be an issue. Right now, this only supports inspecting the first 12 (of 16) stack elements (stack_peek_1 to stack_peek_12). The reason is, that we need to have space on the stack for the logging an returning to the calling position after the logging (the first 4 stack elements in the stack_peek_* are reserved for this functionality) (dev note: maybe we could swap the data we need for logging and routine returning temporarly to memory in order access the full stack.).

Example:

0x01
0x02
stack_peek_1
stack_peek_2
stop

would lead to the following logging (events):

0x00000000000000000000000000000001 0x00000000000000000000000000000002
0x00000000000000000000000000000002 0x00000000000000000000000000000001