You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The protocol expects that sourceReference be less than (2^31)-1, but we currently represent memory address as source reference, this can be truncated either when sending through json or by the client. Instead, generate new source references based on the memory address.
Make the CreateSource function return an optional source.
I passed the create_reference function to CreateSource to avoid the cyclic dependency of ProtocolUtils with DAP
The protocol expects that sourceReference be less than (2^31)-1, but we currently represent memory address as source reference, this can be truncated either when sending through json or by the client. Instead, generate new source references based on the memory address.
Make the CreateSource function return an optional source.
I passed the create_reference function to CreateSource to avoid the cyclic dependency of ProtocolUtils with DAP
The reason will be displayed to describe this comment to others. Learn more.
Should we move this into the DAP? Something like optional<Source> DAP::ResolveSource(SBAddress, SBTarget); that creates or returns a source for the given address?
Or we could move the actual address info into the adapterData field and then we don't need to track the address in the DAP, we'd just need to have some way of hashing the address into a unique sourceReference.
The reason will be displayed to describe this comment to others. Learn more.
Should we move this into the DAP? Something like optional DAP::ResolveSource(SBAddress, SBTarget); that creates or returns a source for the given address?
I am leaning towards this because there may be clients that do not support the optional source argument in SourceRequest
The protocol expects that `sourceReference` be less than `(2^31)-1`, but we currently represent memory address as source reference, this can be truncated either when sending through json or by the client. Instead, generate new source references based on the memory address.
Make the `CreateSource` function return an optional source.
# Conflicts:
# lldb/tools/lldb-dap/Handler/DisassembleRequestHandler.cpp
To make sure I understand the problem: for assembly sources, we use the memory address (i.e. the PC) as the sourceReference rather than using a monotonically increasing number that identifies a unique source? If that's the case, then I assume that was done to avoid generating a unique reference for every address as we're instruction stepping through assembly code? Does this patch address that, or is this not a concern, or am I misunderstanding the problem?
I assume that was done to avoid generating a unique reference for address as we're instruction stepping through assembly code? Does this patch address that, or is this not a concern.
Yes this is the case, it may get truncated since the memory address is larger than the size of the sourceReference specified in the spec.
The reason will be displayed to describe this comment to others. Learn more.
I looked at the code some more and it seems like we return the address of the symbol if there is one, and only use the actual address (i.e. the pc) when there is none. I was trying to find the code that computes the line in that case (i.e. pc - symbol) and I couldn't immediately find it.
I think this PR is fine in the sense that it improves the status quo, but we probably want to take a more wholistic approach at this problem at some point. For example, if we don't have a symbol, it would be nice to have a source reference for a given range (say the next 64 or 128 instructions) and then as we step keep using that sourceReference but bump the "relative line number" in that artificial source file.
I looked at the code some more and it seems like we return the address of the symbol if there is one, and only use the actual address (i.e. the pc) when there is none. I was trying to find the code that computes the line in that case (i.e. pc - symbol) and I couldn't immediately find it.
if (static_cast<size_t>(reference) > source_references.size())
return std::nullopt;
return source_references[reference - 1];
}
I think this PR is fine in the sense that it improves the status quo, but we probably want to take a more wholistic approach at this problem at some point. For example, if we don't have a symbol, it would be nice to have a source reference for a given range (say the next 64 or 128 instructions) and then as we step keep using that sourceReference but bump the "relative line number" in that artificial source file.
it would be nice to have a source reference for a given range (say the next 64 or 128 instructions) and then as we step keep using that sourceReference but bump the "relative line number" in that artificial source file.
I can't think of a state when debugging that we will require a source reference for an address without a symbol. The more I think of it.
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.
The protocol expects that
sourceReference
be less than(2^31)-1
, but we currently represent memory address as source reference, this can be truncated either when sending through json or by the client. Instead, generate new source references based on the memory address.Make the
CreateSource
function return an optional source.I passed the
create_reference
function toCreateSource
to avoid the cyclic dependency ofProtocolUtils
withDAP