format
format copied to clipboard
ethdebug
Smart contract debugging data format – Standards development working group
At DevCon in Bogotá, we discussed a number of separate points. We need to review those to make sure everything is accounted for.
Attempts to clarify what the located type does and how it would be used to model existing solidity types and the future plans for explicit data locations. Once again tagging...
The current document says we'll exclude doing this because it's impractical; I think it's likely doable and would like suggest doing it.
We need a more robust way to represent variables in different cases. As it is in the format currently, we can map stack slots to variables but can't do vice...
- Currently the spec says that the `definitionScope` field contains two fields, one of which is also called `definitionScope`. Could be intentional but looks like a mistake, especially given that...
As proposed by the format, information about the function that is about to be jumped into will be attached to the jump instruction itself. In case of inline-ed functions we...
This is issue can be considered future-proofing, since it refers to features that are only at the design stage now, but I wanted to at least bring it to your...
A compilation pipeline can consist of multiple stages, for us solidity-yul, yul-evmasm and evmasm-bytecode. The format allows multiple source locations, i.e. ``source`` is a list. I'd suggest to give it...
[copied from matrix] The stack information seems to assume that there is a one-to-one correspondance between high-level types and stack slots, which is not the case (e.g. calldata references for...
[copied from matrix] For the stack layouts, I'm wondering if it is necessary to produce them at the same granularity as source maps or whether that's excessive. Tooling/debuggers should be...