Proposal: Support for reading registers about debug-adapter-protocol HOT 36 CLOSED

@PavelSosin I think you misunderstand this very modest proposal. Also, please pick a more open tone in the future.

This proposal has the following impact: if you have a debug adapter, such as C++ debug adapter, where showing register values would be useful, AND if you want to plug into a debugger UI, such as Visual Studio, where there is a special window for showing registers, then this proposal is how the debug adapter and UI can communicate over which scope contains registers. This is all this does. If you own a debug adapter and you don't want to provide registers - not a problem. If you own a debugger UI and you don't want to display registers in a special way - not a problem either.

from debug-adapter-protocol.

@andrewcrawley, @gregg-miskelly @pieandcakes

This is great. Can I help to implement/prototype this in MIEngine? Not sure how to proceed

from debug-adapter-protocol.

I vote No ! Debug Adapter Protocol means High Level Language Debug Adapter protocol. High Level language is abstraction which allows to write code without dealing with architecture. Reading registers breaks this abstraction. Even Cuda is abstraction. I know that I can use java to program Arm. I have very little interest in where registers are in Arm, how GPU memory is addressed and which elements of CPU participate in hardware acceleration. There are better places to discuss driver debugging protocol

from debug-adapter-protocol.

@PavelSosin I totally disagree. All applications run on real hardware, and pretty much all real hardware has registers, memory and a processor. Debuggers are for real applications, not "high level languages". How does preventing viewing registers aid debugging?

I think this proposal is very sensible.

from debug-adapter-protocol.

@PavelSosin Perhaps you misunderstand. This is an optional capability that only makes sense for certain Debug Adapters and only those adapters will advertise it. Clients GUIs do not even have to use it. No one else is affected. For instance, the Scripts window in VSCode is not for everyone and is not shown when debugging C/C++. Nothing to do with driver development. Some (millions) of us still have to use C/C++ but even those have little interest in seeing registers. But, when something goes wrong, or we need the absolute best performance, this is needed -- sometimes to give you those high-level abstracted languages. Rust is another language that can use it.

Final note: There are millions of embedded/IoT developers who would just love VStudio/VSCode besides desktop developers.

I noticed you also posted similar views in issue #42 Same deal.

from debug-adapter-protocol.

Btw, I have my own experimental extension to see registers. It is ugly and not performant. A hack really. But it works.

I recently submitted a patch to MIEngine debug adapter, so somewhat familiar with the code and thus offering to help. It is still a proposal stage, we need a prototype to make sure.

CC: @gregg-miskelly @pieandcakes

from debug-adapter-protocol.

@andrewcrawley Trying to understand a bit. @gregg-miskelly his idea was that registers simply show up in the Variables window as a separate scope regardless of what part of the stack/frame you are looking at. So this proposal says simply what name a DA has decided to use/implement? If a client (UI) wants to know where registers exist and how to display them, this is the name they would look for.

As of today, a DA can already add scopes/nesting (real or made-up). This proposal simply says the DA can advertise the root-name of a scope meant for 'processor' registers. Totally innocuous.

from debug-adapter-protocol.

Unfortunately, something ugly ans not aligned with other debuggers behavior can't pass through our UX. As it is known to me nobody in our Debugger team knows C++ and we have only one team responsible on Debugging features for all languages. We have only one team responsible on Editors too. They work strictly by Protocol definition. Everything has to be encapsulated in Protocol itself and client and server capabilities. Every debugger UI inherits 90% of capabilities from "abstract" debugger UI. Protocol standard should reflect abstract debugger UI communication with abstract debugging server. I don't expect that people developing Java debugging core jdt are specialists in WebUI. DAP for C++, DAP for Go and DAP for typescript are nonsense. We have only one LSP protocol which serves all languages and all editors. Language specific extensions are allowed but UI should be decoupled from server anyway.

from debug-adapter-protocol.

@haneefdm this idea is a slight refinement to my original idea -- instead of showing it as a pseudo-variable, we can instead display them as a pseudo-scope. We can create the scope with the `expensive = true;`` to it will just show up in VS Code in an unobtrusive way. This proposal just lets us hookup to the registers Window in VS.

from debug-adapter-protocol.

Yes the scopes are a good choice for this IMO.

Indeed, I seem to recall that one existing debug adapter that uses lldb already does exactly this.

from debug-adapter-protocol.

@gregg-miskelly Yes, I understood as that. For some reason, I thought you also said scopes or thats how I took it. Thank you for the specific line link to the schema. You all are awesome.

This proposal just lets us hookup to the registers Window in VS.

Did you mean the existing variables window? Looking to clarify.

from debug-adapter-protocol.

@haneefdm: VS has a "Registers" window that is separate from the "Variables" window - look at Debug -> Windows -> Registers. Here's an example:

In this case, the window was populated via the following requests (I've snipped out the irrelevant messages):

 1> --> C (scopes-30): {"command":"scopes","arguments":{"frameId":1000},"seq":30,"type":"request"}
 1> <--   R (scopes-30) [9 ms]: {"seq":51,"type":"response","request_seq":30,"success":true,"command":"scopes","message":"","body":{"scopes":[{"name":"Locals","variablesReference":1000,"expensive":false},{"name":"Registers","variablesReference":1001,"expensive":true}]}}

 1> --> C (variables-32): {"command":"variables","arguments":{"variablesReference":1001,"format":{"hex":true},"timeout":2000},"seq":32,"type":"request"}
 1> <--   R (variables-32) [15 ms]: {"seq":53,"type":"response","request_seq":32,"success":true,"command":"variables","message":"","body":{"variables":[{"name":"CPU","value":"","variablesReference":1006},{"name":"CPU Segments","value":"","variablesReference":1007},{"name":"Floating Point","value":"","variablesReference":1008},{"name":"MMX","value":"","variablesReference":1009},{"name":"SSE","value":"","variablesReference":1010},{"name":"AVX","value":"","variablesReference":1011},{"name":"MPX","value":"","variablesReference":1012},{"name":"Flags","value":"","variablesReference":1013}]}}

 1> --> C (variables-35): {"command":"variables","arguments":{"variablesReference":1006,"format":{"hex":true},"timeout":2000},"seq":35,"type":"request"}
 1> <--   R (variables-35) [5 ms]: {"seq":56,"type":"response","request_seq":35,"success":true,"command":"variables","message":"","body":{"variables":[{"name":"EAX","value":"00000001","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"EBX","value":"011AF000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"ECX","value":"1FB80000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"EDX","value":"00000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"ESI","value":"0133F5DC","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"EDI","value":"0133F720","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"EIP","value":"00A81F68","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"ESP","value":"0133F5DC","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"EBP","value":"0133F720","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"EFL","value":"00000246","presentationHint":{"attributes":["readOnly"]},"variablesReference":0}]}}

 1> --> C (variables-42): {"command":"variables","arguments":{"variablesReference":1013,"format":{"hex":true},"timeout":2000},"seq":42,"type":"request"}
 1> <--   R (variables-42) [5 ms]: {"seq":63,"type":"response","request_seq":42,"success":true,"command":"variables","message":"","body":{"variables":[{"name":"OV","value":"0","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"UP","value":"0","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"EI","value":"1","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"PL","value":"0","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"ZR","value":"1","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"AC","value":"0","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"PE","value":"1","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"CY","value":"0","presentationHint":{"attributes":["readOnly"]},"variablesReference":0}]}}

You can see the extra "Registers" scope being returned in the first response.

from debug-adapter-protocol.

@andrewcrawley Thanks. Yes, I am familiar with the VS Registers window -- lived int for several months :-). That is exactly how I envisioned the scopes to show up from the adapter.

May I ask the format used by these variables values? For instance, some could be FP registers, displaying as hex values is cumbersome. In the watch window I can set the format, but not elsewhere

I am sure the following is not relevant to the DAP ... more of a UI/UX thing.

We can create a separate window in the debug section of the sidebar in VSCode. It is getting crowded over there, so I was also thinking why not just stuff it the variables window. as a separate scope. Right now, we just have one scope called 'Locals' for C/C++. There are pros and cons to both ways. I've seen one C/C++ extension which puts 'Globals' in the variable windows. And, others have many Blocks and Closures in there as well.

It is fine either way separate TreeView or add to the variables TreeView

I have to think a bit more; locals get updated as you move up and down frames or switch threads. I did a hack to show registers in a separate window. You are thinking something like that?

from debug-adapter-protocol.

@haneefdm: Ah, sorry, I misunderstood what you were asking.

The format of the register values is up to the adapter, since they're provided as strings. VS doesn't attempt to do any parsing, and none of the VS settings for hex vs decimal affect the output. For reference, here's the complete set of registers returned by vsdbg, which includes floats, 256-bit AVX registers, etc:

 1> --> C (variables-35): {"command":"variables","arguments":{"variablesReference":1006,"format":{"hex":true},"timeout":2000},"seq":35,"type":"request"}
 1> <--   R (variables-35) [5 ms]: {"seq":56,"type":"response","request_seq":35,"success":true,"command":"variables","message":"","body":{"variables":[{"name":"EAX","value":"00000001","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"EBX","value":"011AF000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"ECX","value":"1FB80000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"EDX","value":"00000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"ESI","value":"0133F5DC","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"EDI","value":"0133F720","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"EIP","value":"00A81F68","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"ESP","value":"0133F5DC","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"EBP","value":"0133F720","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"EFL","value":"00000246","presentationHint":{"attributes":["readOnly"]},"variablesReference":0}]}}
 1> --> C (variables-36): {"command":"variables","arguments":{"variablesReference":1007,"format":{"hex":true},"timeout":2000},"seq":36,"type":"request"}
 1> <--   R (variables-36) [4 ms]: {"seq":57,"type":"response","request_seq":36,"success":true,"command":"variables","message":"","body":{"variables":[{"name":"CS","value":"0023","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"DS","value":"002B","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"ES","value":"002B","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"SS","value":"002B","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"FS","value":"0053","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"GS","value":"002B","presentationHint":{"attributes":["readOnly"]},"variablesReference":0}]}}
 1> --> C (variables-37): {"command":"variables","arguments":{"variablesReference":1008,"format":{"hex":true},"timeout":2000},"seq":37,"type":"request"}
 1> <--   R (variables-37) [5 ms]: {"seq":58,"type":"response","request_seq":37,"success":true,"command":"variables","message":"","body":{"variables":[{"name":"ST0","value":"+0.0000000000000000e+0000  ","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"ST1","value":"+0.0000000000000000e+0000  ","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"ST2","value":"+0.0000000000000000e+0000  ","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"ST3","value":"+0.0000000000000000e+0000  ","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"ST4","value":"+0.0000000000000000e+0000  ","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"ST5","value":"+0.0000000000000000e+0000  ","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"ST6","value":"+0.0000000000000000e+0000  ","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"ST7","value":"+0.0000000000000000e+0000  ","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"CTRL","value":"027F","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"STAT","value":"0000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"TAGS","value":"FFFF","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"EIP","value":"00000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"EDO","value":"00000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0}]}}
 1> --> C (variables-38): {"command":"variables","arguments":{"variablesReference":1009,"format":{"hex":true},"timeout":2000},"seq":38,"type":"request"}
 1> <--   R (variables-38) [5 ms]: {"seq":59,"type":"response","request_seq":38,"success":true,"command":"variables","message":"","body":{"variables":[{"name":"MM0","value":"0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"MM1","value":"0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"MM2","value":"0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"MM3","value":"0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"MM4","value":"0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"MM5","value":"0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"MM6","value":"0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"MM7","value":"0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0}]}}
 1> --> C (variables-39): {"command":"variables","arguments":{"variablesReference":1010,"format":{"hex":true},"timeout":2000},"seq":39,"type":"request"}
 1> <--   R (variables-39) [5 ms]: {"seq":60,"type":"response","request_seq":39,"success":true,"command":"variables","message":"","body":{"variables":[{"name":"XMM0","value":"0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"XMM1","value":"0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"XMM2","value":"0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"XMM3","value":"0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"XMM4","value":"0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"XMM5","value":"0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"XMM6","value":"0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"XMM7","value":"0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"MXCSR","value":"00001F80","presentationHint":{"attributes":["readOnly"]},"variablesReference":0}]}}
 1> --> C (variables-40): {"command":"variables","arguments":{"variablesReference":1011,"format":{"hex":true},"timeout":2000},"seq":40,"type":"request"}
 1> <--   R (variables-40) [15 ms]: {"seq":61,"type":"response","request_seq":40,"success":true,"command":"variables","message":"","body":{"variables":[{"name":"YMM0","value":"0000000000000000-0000000000000000-0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"YMM1","value":"0000000000000000-0000000000000000-0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"YMM2","value":"0000000000000000-0000000000000000-0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"YMM3","value":"0000000000000000-0000000000000000-0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"YMM4","value":"0000000000000000-0000000000000000-0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"YMM5","value":"0000000000000000-0000000000000000-0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"YMM6","value":"0000000000000000-0000000000000000-0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"YMM7","value":"0000000000000000-0000000000000000-0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0}]}}
 1> --> C (variables-41): {"command":"variables","arguments":{"variablesReference":1012,"format":{"hex":true},"timeout":2000},"seq":41,"type":"request"}
 1> <--   R (variables-41) [6 ms]: {"seq":62,"type":"response","request_seq":41,"success":true,"command":"variables","message":"","body":{"variables":[{"name":"BND0","value":"0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"BND1","value":"0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"BND2","value":"0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"BND3","value":"0000000000000000-0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"BNDCFGU","value":"0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"BNDSTATUS","value":"0000000000000000","presentationHint":{"attributes":["readOnly"]},"variablesReference":0}]}}
 1> --> C (variables-42): {"command":"variables","arguments":{"variablesReference":1013,"format":{"hex":true},"timeout":2000},"seq":42,"type":"request"}
 1> <--   R (variables-42) [5 ms]: {"seq":63,"type":"response","request_seq":42,"success":true,"command":"variables","message":"","body":{"variables":[{"name":"OV","value":"0","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"UP","value":"0","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"EI","value":"1","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"PL","value":"0","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"ZR","value":"1","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"AC","value":"0","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"PE","value":"1","presentationHint":{"attributes":["readOnly"]},"variablesReference":0},{"name":"CY","value":"0","presentationHint":{"attributes":["readOnly"]},"variablesReference":0}]}}

Showing the registers in the "Variables" section as a separate scope sounds fine to me. I believe this is the default behavior for scopes, so it would be the easiest option as well : )

from debug-adapter-protocol.

Shouldn't it respect "format":{"hex":true}?

from debug-adapter-protocol.

Thanks @andrewcrawley Since most of those windows/panels are actually created in VSCode core, we had some resistance to adding any more. It could be done in cpptools as well, where it could also take control of the formatting. Will discuss with the cpptools team for advice/ideas. But doing it in the DA makes the most sense to me ... as of yet.

from debug-adapter-protocol.

@int19h: Sorry, I was trying to say that VS always requests register values in hex, regardless of any user-visible settings in VS. The debug adapter is free to ignore that and return a format that makes more sense (such as for the float registers @haneefdm brought up), which is what vsdbg does.

from debug-adapter-protocol.

Now I gather what is the point. I hope there is no intention to build naked gdb as Debugger server core. Creation of Debugger server around https://github.com/microsoft/MIEngine makes sense. It is also usable in development for Linux. because Linux containers run in Cloud infrastructure en mass. But MIEngine based LSP server has to be implemented first! Otherwise developer will not have something to debug. Please, explain how you DAP request and response are mapped to MI, at least, roughly. Code authoring, debugging and CI should be integrated into the same Environment.

from debug-adapter-protocol.

@andrewcrawley I like this proposal because it is perfectly aligned with the original intent of scopes. Adding the word "Register" to the comment appears to be a very natural thing:

The only slightly ugly issue comes with NLS:
As long as names are just rendered in the UI but not interpreted, the DA can just return a localised version of name without confusing the client.

But by introducing a registersScopeName capability, the client is asked to interpret specific scope names. That means the name specified for the registersScopeName capability must be the localised version of name as well. This is still somewhat OK...

An alternative, cleaner approach would be to add a new optional kind attribute to Scope with (at the moment) one predefined value register. With this approach we would not need the registersScopeName capability.

from debug-adapter-protocol.

Another thing I like about showing the registers as an additional scope in the Variables window is that registers values are relative to the current frame and all of the code to track/update that already exists.

from debug-adapter-protocol.

I like it too. "Registers" scope can be shown only if it exists. Are values in this scope mutable?

from debug-adapter-protocol.

@PavelSosin You mean can the user modify them. Yes, I believe so, with sometimes disastrous effects. Not sure what debuggers do if you are not at the top of the frame though.

from debug-adapter-protocol.

@weinand: The main concern I have with that approach is that it would be possible to flag more than one scope with kind=registers. The VS host would likely choose to emit a warning and ignore all but the first in this case. Specifying the scope name in the adapter's Capabilities enforces that there should only be a single "registers" scope.

If you want to go this route, it seems like we might as well define the other kind values from the comment (arguments and locals) while we're at it.

from debug-adapter-protocol.

No need in arguments scope - arguments are always local variables.
User always can cause crash changing application state - this is acceptable. Restart of debugging session with reset of application state is not a part of protocol. Entire area of debugging session state management (start, re-start, abort, continue ) is not covered by the protocol yet. Most of debuggers support it.

from debug-adapter-protocol.

For me the capabilities is something that the debug adapter is capable of doing. Specifying the registerScopeName feels like it does not belong there.
Since this information is more scope specific it makes sense to me to live in the Scope as @weinand suggests.

As for having multiple scopes of kind = regsiters, I feel like it is up to the debug adapter to make sure this does not happen and that it is emitting proper scope data.

from debug-adapter-protocol.

@andrewcrawley if it's OK with you, I will implement the kind based approach because it avoids the problem that clients have to interpret localisable UI values (which is not done anywhere else in DAP).

IMO the issue of having multiple scopes flagged as "registers" is minor in comparison and I will address it in the attribute's documentation.

As you suggested I will also add values for "arguments" and "locals".

from debug-adapter-protocol.

@weinand @andrewcrawley I must be missing something. Yes, the value of registersScopeName has to be localized. But as a client as in the UI, I probably do not worry what the value is. If I want the registers, I simply query the DA using the value of registersScopeName. If I query for a list of scopes, and if a scope name matches the value of registersScopeName, I know that that scope is for registers.

If you do the kind based approach, there are so many of those for all kinds of languages, I am not even sure how to enumerate them all. Locals/Globals/Arguments/Closures/Block/File-Static/Other.

Either approach is fine but just wanted to bring it up. I am not worried of duplicates either

from debug-adapter-protocol.

@haneefdm you are correct that a client does not have to worry about the value of the registersScopeName capability.

However, DAP's approach to conveying "semantics" vs. "just strings" is as follows:

• as long as we expect that clients have no need to understand the semantics of specific UI strings, we just send strings (which can be modified (e.g. through localisation) without danger).
• if we see a need for clients to understand the semantics of specific strings, we introduce an additional attribute to convey the semantics. One past example was the introduction of the description attribute for the StoppedEvent which only had a reason attribute initially (and people were starting to "scrape" those strings to understand the semantics of the event).

Introducing an additional attribute is less error prone than using the registersScopeName approach, because it does not require that two strings are changed in a consistent way in two source locations.

The scope "kind" is what I call an "open-ended enum". That means it is not a fixed set of all possible values but it only contains those few values that we can all agree on and we can add more values to it in the future.

So for this proposal it would be sufficient to just have "registers" in the enum.
"arguments" and "locals" were only included because they are already part of the Scope's documentation. But there is no need for an exhaustive set of values.

from debug-adapter-protocol.

One additional note -- we only need to add a new 'kind' value when there exists at least one client that has special handling of a particular scope type. For example, Visual Studio has a registers window so we need that one. If, in the future, some other debugger UI that wants to become a DAP client has a Globals window, we could add that kind value for that. But there is no reason to do so now since the enum can always be extended.

from debug-adapter-protocol.

Alright, sounds good to me!

from debug-adapter-protocol.

I think that Andre Weinand has real experience with application development for Arm architecture. Arm architecture is not similar to Intel architecture. Arm memory structure differs from Intel memory structure. Arm assembler is not like Intel assembler. Every high level language has own abstraction. Every programming language assumes own run-time with own low-level debugging protocol. I suppose it is not good idea to build Debugger client-server communication on Server-Client capabilities exchange. Debugger UI and Debugger Server simply know the language semantics and all language and architecture specific information could be sent via qualifiers. Function can be qualified as "function". Memory addresses can be qualified as "memory", Registers can be qualified as "register" or "register of kind". Operations - display, set, step, step-into, step-over, run, continue-to, set-breakpoint, clear-breakpoint, watch are universal. Stack and stack frame are also universal. It is strange to think how debugger can not to support them and every Server implementation must support them. validity of certain operation and qualifier combinations should be enabled or disabled by UI based on its knowledge of context and accepted or rejected by server based on its knowledge of context in run-time. UI displays values provided by server based
of its interpretation of qualifiers. Implementations of UI and server are based on Language context and low-level debugging protocol capabilities. All kinds of UIs and Server extend abstract UI and abstract server.

from debug-adapter-protocol.

@weinand I got ya, about scope kind enum stuff.

Non-technical stuff below...

@PavelSosin I will never ever claim to be an expert in anything. But I have some real experience with these things from bare metal (various CPUs) to high-level programming and their tools. Or else, I wouldn't be in this thread. I don't understand your characterization about what we are trying to do. I see it as a real-world need that I don't see changing anytime soon. When it does, everyone will adapt. Tools first. I hope you really look into the ecosystem these features serve, user profiles, CPUs/MCUs, IoT -- significant # of developers/products. Sorry, I can't quote numbers but just look around you and think about how those things were developed and debugged.

If DAP and/or VSCode+extensions have no interest in including this class of users, then we are done. End of conversation. But, I see hope. VSCode is awesome and other tools can also leverage from this work on the DAP.

from debug-adapter-protocol.

@andrewcrawley @gregg-miskelly I've created PR #49 for the complete DAP change.

from debug-adapter-protocol.

@weinand
I think that Product Vscode IDE is so popular among developers because it is easily extensible and developers can find many very usable extensions which fulfill their requirements. I'm wondering when we finally agree what we are discussing - design proposal of Vscode extension which can be offered via marketplace channel or backbone protocol which is used by various IDE products and has implementation cost which allows to place debugger implementation at the head of team's backlog. In SAP and RedHat teams involved into IDE development means dozens of employers - POs, UX, UI designers, developers, DevOps, etc. If implementation cost is too high and added value is not so high the feature will never reach GA. I think your proposal is falls into category of extension proposal. It is absolutely valid that extension is designed and developed by single developer and consumed by 5 users over the world from product marketplace. It is absolutely unacceptable when proposal fits to 5 developers need but makes product inconsistent and miss-lead 100 developers. Such proposal is not even considered for implementation. I feel that your proposal can be implemented according existing Vscode extensibility model and without costly for implementation protocol changes. Please, argue what are benefits it gives to other Vscode extensions developers and how its implementation can be consumed by users.

from debug-adapter-protocol.

The requested feature has been implemented in VisualStudio 2019: VS2019- registers window. Implementation in VSCode will be redundant.

from debug-adapter-protocol.

So your statement is: every DAP feature that is implemented in more than one client is redundant, right?

from debug-adapter-protocol.