Add call-targets to the info available via +beam_debug_info #9814
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
At the moment, we are only saving frame-size and var mappings
as debug-info, but we are planning to add more information.
Because code:get_debug_info/1 returns the current info in a
tuple, it will not be possible to add more fields without
making breaking changes.
So instead use a map `#{frame_size => ..., vars => ...}`, so that
new fields can be added in the future by extending this map
At the moment, we only store frame-size and var-mappings in the DbgB chunk, but we would like to store more information. This will require to bump the version of the chunk encoding. In doing this, we would like to make it so that it is easier to extend this in the future retaining backwards compatibility. Where today every item is encoded with a `call` instruction, where the first argument is the frame size and the secod one it the var mapping, we will now use a `call` instruction with the first argument being a key (for now "frame size" or "var mappings"), and the second a payload. As long as the loader is prepared for missing entries, we retain backwards compatibility.
At the moment, we only expose frame-size and variable-mappings when compiling with `+beam_debug_info`. Internally, they are stored as a tuple. We are planning to add more debug-info, but this will mean changing all places where the tuple is used, to turn it into a triple, and the same will happen if we later add another one, etc. So to make this refactorings easier, we introduce a map.
We extend the DbgB chunk with an optional list of all calls
performed at a debug_line. Calls are expressed as:
* {M, F, A} for remote calls,
* {F, A} for local calls,
* V for variables (fun refs, etc)
M and F above can be either atoms or user variables
During code loading, we now also save the new calls debug info, and use it to build the response in `code:get_debug_info/1`
CT Test Results 5 files 523 suites 2h 0m 0s ⏱️ For more details on these failures, see this check. Results for commit 86062ed. ♻️ This comment has been updated with latest results. To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass. See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally. Artifacts
// Erlang/OTP Github Action Bot |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
For implementing a stepping-into functionality, we need to know, given the current location of a suspended process, what are the possible next targets. At the moment, the edb debugger is relying on the AST we get via
+debug_info. This however has several drawbacks; in particular we are forced to implement a code-analysis that is tricky to get right, requires maintenance as new language constructs are added (similar to what happens withint) and limits this feature to modules that are backed by a file, and compiled with+debug_info.Instead, we'd like this info to be provided by the compiler when
+beam_debug_infois used, as an additional bit of data associated to each debug location.What we do here
code:get_debug_info/1so that it uses a map, instead of a tuple, to return the data. This means we can add more keys in the future, without major API changescall FrameSize VarMappings, we now use one call for theFrameSizeand an optionalcallfor the VarMappings. The first argument of thecall` now tell us what the payload in the second argument is.callinstructions and record their target. The targets we care about are of the form{M, F, A}or{F, A}, whereMandFcan be atoms, if they are known statically, or a binary representing a user variable, for dynamic calls. We also allow plain user variables as target. This will allow edb to soon support stepping-into the target of a dynamic call.callinstruction is as a list of integers, binaries or atoms, as follows:[{M, F, A},...]gets encoded as[A,M,F,...];[{F, A}, ...]gets encoded as[A+256, F, ...];[V,...](for V a binary) gets encoded as[V,...]We can then unambiguously reconstruct the list of targets from this list of terms