Repository navigation
Semantic information for matching internal function pointers with function definitions #290
Description
In #282 (comment) when describing the function type I mentioned the problem of mapping internal function pointer values to existing functions. I think it's worth considering it as a separate problem.
Solidity currently solves this by providing that information in the AST (argotorg/solidity#13425). Perhaps it would make sense to make it a part of the ethdebug format. On the call last week the sentiment leaned towards including such extra semantic information when available rather than leaving it for the debugger to figure out based on other information it can get from the compiler.
Activity
gnidan commentedon Aug 10, 2026
Ooh, how might the compiler provide this information? I was thinking that debuggers might simply have to step ahead to see where the function pointer PC resolves, since that instruction would theoretically have its own function definition context info.
cameel commentedon Aug 10, 2026
Well, currently it gives you the
internalFunctionIDfield onFunctionDefinitionnodes in the AST. Or are you asking how it would work in ethdebug? I'd expect some global translation table (one per contract).We'd have to account for the fact that these values may not be simple IDs. For example they might only be unique given a specific signature (I vaguely remember that this is what we do via IR, though not 100% sure now) or they may be a combination of creation- and deploy-time jump address packed into a single value. But it should still be doable.
This may not be that simple for a debugger, at least without making assumptions what the code generated for an internal function call looks like. For example, when a function is called via a pointer in the IR codegen, the first function you encounter is the internal dispatch function. That then has a big
switchwith separate cases for calling all the available internal functions. On the other hand in the evmasm codegen it's the first jump that takes you directly to the function.Also, that only helps you if you're inspecting the pointer at the point where it's called. What if you see it elsewhere, e.g. passed via a parameter into a function. It seems to me that it might be problematic for a debugger to have to track down some point down the line where that pointer is called. It might even not be called at all, just passed around and stored.