-
Notifications
You must be signed in to change notification settings - Fork 8
Description
The current approach to finding the DIE that contains runtime information about a variable (by the variable's name) consists of two steps:
- We continually narrow the range of potential DIEs until we end up in a range that can only contain the variable we are looking for once (i.e., the scope of the function that contains the given PC)
- If no such range could be found, we traverse the entire DIE tree again, this time ignoring scope and choosing the first occurrence we find.
(This is implemented in the sd_runtime_variable function in src/spray_dwarf.c. It's documented here)
The problem of this top-down approach is that it's opposite to how variable scopes work. At any point in the program, when trying to access a variable, the closest one to the instruction pointer (PC) should be selected.
It appears that the current approach word fine (so far) for C because, in C, functions are not nested. This means that we are usually limited to two types of variables: those in the global scope and those in the current function.
The more general and reliable approach would be to build up a new tree of potential variables from the DIE tree and then traverse this variables tree, starting at the point closest to the given PC. If code blocks create new variable scopes, this would likely be the more correct approach (I haven't checked if nested {} blocks are reflected in the DWARF info at runtime).
TODO
- Find out how re-declaring variables and shadowing in nested scopes (e.g., {int a; {int a;}}) is reflected in DWARF info.
- Find a concrete example of how the current approach fails. Use it as a test.
- Act like inlining doesn't exist ... 🤫