Add support for bytecode source map

[elfedy]

🌟 Feature Request

📝 Description

Beside the mapping given for the ast, solc provides bytecode source maps, that can be output by specifying the evm.bytecode.sourceMap/evm.deployedBytecode.sourceMap output selection options.

In that map, each opcode has the following information as a ; separated list:

• source file
• code region associated (source code byte offset + length)
• jump metadata (indicates when a jump goes into a function or returns from a function)
• modifier depth (associated to modifiers, entering the _ statement will increase the depth by 1, returning from it will decrease it)

A quick glance at the current outputs, the docs and supported output flags would indicate that this is not supported in zksolc still.

🤔 Rationale

This feature is needed for developers trying to implement debuggers or any tool that analyzes execution and needs to map an execution step back to a place in the source code that produced it.

📋 Additional Context

We are looking to support forge coverage in foundry zksync which outputs test coverage data for functions/statemens/branches/lines. In order to implement this we would need a way to map an instruction being executed on the Era VM to a corresponding part of the contract source code to check what was exactly hit during test execution. Even though research needs to be done still, this will probably be a requirement to support the debugger as well.

[TalbenXu]

I think the source map feature would be a great addition, and I’d be happy to contribute to it as an open-source contributor.

I was wondering if this feature is already on the team's schedule or if it's something being considered for future releases? I’d love to get more information on its status.

[hedgar2017]

Hey @TalbenXu - thank you for showing interest in contribution to our toolchain!

This has been planned, but we don't have the exact timeline on when we can start the implementation. It is quite resource-demanding as the debug information must be propagated from Solidity/Yul through all phases and IRs of the LLVM framework.

Solidity/Yul-to-LLVM IR is a part with the friendliest learning curve. It's where the DWARF debug info must be generated for our Yul translator, and optionally for our EVM assembly translator using our fork of the LLVM library 'inkwell'. Afterwards, we'll have to propagate the debug information further down the pipeline on the LLVM side, and of course connect it with the Solidity source maps provided by solc.

[TalbenXu]

Hi @hedgar2017,

Thank you for the thoughtful response and for outlining the challenges involved. I might start by generating DWARF debug info in the Yul-to-LLVM IR phase.