GotoTarget lifetime

[int19h]

The specification does not define the lifetime of a GotoTarget as obtained from a given GotoTargetsRequest, so it is unclear if it's legal for an IDE to cache them and reuse them later (possibly across goto, across continue, or in different frames that just happen to use the same source), or whether the adapter can clean up associated resources more aggressively - e.g. on invalidate them on every goto.

It's also unclear whether the adapter can return different IDs for the same file/line on a subsequent request, even if it ensures that old IDs are still valid to use in goto - and if it can do so, then how should the IDE interpret this.

[gregg-miskelly]

CC @andrewcrawley

My suggested documentation: Ids are valid until the next continue. If multiple GotoTargetsRequest are issued by a client, the debug adapter is allowed, but not required, to return the same id if the underlying execution location is the same between the two requests.

[Trass3r]

Could someone explain a use-case for doing multiple GotoTargetsRequests in a row?
VSCode just issues 1 targets request and directly feeds the id into the goto request for its Jump to Cursor functionality, ignoring anything else inside the GotoTarget: debugCommands.ts
This adapter already relies on this by returning a dummy GotoTarget with id 1 and the same source line given in the request and then simply remembers the last requested target.

I can barely come up with an example for returning more than 1 target (template functions come to mind but why would it be ambiguous if you are already in the same function) let alone multiple target requests.
Also I don't know what the other GotoTarget fields could be useful for (line? we already requested a specific line).

[gregg-miskelly]

I am not sure why a client might want to issue multiple gotoTargets requests, but it also seems wrong not to handle them -- the DAP uses handles in lots of other places, so I don't know why an adapter would do things differently here.

GotoTargetsArguments doesn't specify a thread id, so I don't think an adapter could actually know which template instantiation to return.

line in GotoTarget is useful for the same reason as in breakpoints - the incoming line is where the user requested. But the debug adapter may find that it doesn't have an executable code associated with that line, but it does have executable code associated with lines in close proximity. An IDE could then choose to use that line info in a disambiguation dialog.

FYI: If you are asking about this because you are thinking about implementing this in MIEngine, GotoTargets needs to call IDebugProgram2.EnumCodeContexts.

[Trass3r]

I am not sure why a client might want to issue multiple gotoTargets requests, but it also seems wrong not to handle them -- the DAP uses handles in lots of other places, so I don't know why an adapter would do things differently here.

I guess confusion about the spec like in this ticket, vscode as the reference implementation does it as described above and it makes the implementation much easier (at least if you assume IDs need to be globally unique, that crucial 'certain IDs are valid only until the next continue' information is buried in some tickets on Github, see #60).

GotoTargetsArguments doesn't specify a thread id, so I don't think an adapter could actually know which template instantiation to return.

Interesting. Related to #38.
Any other use-case for multiple locations?

line in GotoTarget is useful for the same reason as in breakpoints - the incoming line is where the user requested. But the debug adapter may find that it doesn't have an executable code associated with that line, but it does have executable code associated with lines in close proximity.

I see, should be added to the docs.

[gregg-miskelly]

Any other use-case for multiple locations?

For compiled languages, I think of the gotoTargets request as akin to asking: "if I was to set a breakpoint on this line, where would the breakpoint mind?" without actually setting the breakpoint. So you could get multiple answers if:

• The function was compiled multiple times (ex: C++ templates)
• The line was mapped to multiple instruction groups (ex: optimizations, compiler bugs, for loops in C-like languages, etc)
• The method was included in multiple modules (ex: inline function defined in C/C++ header file)
• Potentially a managed runtime might JIT a method multiple times (ex: fast JIT and optimizing JIT) and expose that

[Trass3r]

Yeah it's easy to handle breakpoints as for example gdb just sets 1 per associated address. But jump will probably fail if it's ambiguous.

[Trass3r]

I am not sure why a client might want to issue multiple gotoTargets requests

If you want to implement jumping by dragging the current line marker like in VS you'd probably have to do that.
But even then that simple approach of remembering the last request would still work as long as the UI doesn't do caching.