solidity

solidity copied to clipboard

@alcuadrado and others proposed to expose the boundary between code and data in the emitted bytecode ( https://www.notion.so/Miscellaneous-debugging-symbols-Initial-proposal-2948f1a1f74742c0901ad54af05fa1ff ). I think this is a good idea, but we should not stop at only that number.

In essence, we have code, sub-objects (runtime code of the current contract or creation code of created contracts), data and metadata. This structure also matches what we have when we compile Yul objects, so I think a common data format can be found here.

Proposal:

Export an array of sections, each section is a json object of the following form:

{
  start: x, // bytes
  length: n, // bytes
  kind: 'code' / 'data' / 'object' / 'deployObject' / 'metadata',
  name: 'factory.sol:Factory'
]

Why not merge this and the linkReferences too?

We could also add the information about the functions.

discussion: linkreferences and immutables should be in the same structure as "information about a section of the bytecode"

Main open question:

• should it be nested?
• what are the use-cases?

If we have this feature we may consider getting rid of deployedBytecode in the JSON I/O because it could be derived based off it.

The question then is how to deal with the source map, but perhaps it is also possible to have a single large source map (the one for the bytecode) and slice it based off this structure.

This would be very useful. I don't have an opinion about merging those things, nor the format. As long as the info is available in a clear way I'm fine.

I realized that my answer may be pretty ambiguous. I think it would be very useful to also have data about the other elements. I didn't mention those, as I've never had a use for them, but my experience is limited, and I'm sure there are valid uses.

If we have this feature we may consider getting rid of deployedBytecode in the JSON I/O because it could be derived based off it.

tbh I really like having one structure for each bytecode, both with the same type, as they are now.

what are the use-cases?

That would be helpful for extracting the metadata. will immutables also be described? and in that case is there any way that they can be decoded (following the right type), so we can display them in the contract state in the debugger. This look like to be a bit tricky though..

Could also include more detail about EVM: https://github.com/ethereum/solidity/issues/6485#issuecomment-621978068

And #3596 is a semi-related issue.