search

ethdebug / format

Smart contract debugging data format – Standards development working group
https://ethdebug.github.io/format/
47 stars 4 forks source link

Accounting for Code Deduplication #22

Open ekpyron opened 1 year ago

ekpyron commented 1 year ago

[copied from matrix] How well should the format account for code deduplication? To do this properly, basically any bytecode based debugging information would really have to be a list (by default of length 1), s.t. we can preserve all information when deduplicating - and we could even try to annotate jumps, s.t. it's possible to tell which set of information to follow across the jumps.

I'm not keen on maintaining this myself, so if you're fine with loosing information across deduplication, I'm happy, maintaining this correctly would be a mess for us - but "multi-source-maps" seemed to me to generally be a highly-requested feature...

The current format is so far (intentionally) vague about the source location specifiers, but already considers it as a list - my point, though, is that basically all information, including stack maps, etc., are potentially the result of collapsing different paths with different debugging information: For example, the same code can act on a struct S { uint a; uint b; } and a struct VerboselyNamedStruct { uint someField; uint anotherField; }, thus technically you have more than one set of type information associated with stack items, etc. pp.

gnidan commented 1 year ago

Could we do something with context-sensitive marking? Like, annotate some section of bytecode to require knowledge of type context.