Implementation of evaluate request #47
Comments
|
Yeah, I'm cheating. With vscode, there is no interactive console available to the debug session out of the box. So I hooked the expression evaluator up to do straight gdb commands. Great for testing in the beginning :). But yes, the help text in the text box does say expression, not debugger command. Will need to figure out what to do on the vscode side if we want to change it. I think it's probably safe to do it now since we don't really have users yet other than @jcrwilliams and myself. |
|
Have you started to look into how to create custom views in VSCode? Would it be possible to instantiate a separate console view/widget (like the repl), and customize it to send the request with a different |
|
Yeah, we've done a bunch of custom webviews and such. And we'll do custom views for Registers and something with memory. I want to check out the Terminal API to see if we can do it there. I also want to check out how the PlatformIO IDE does this stuff. Love to get those guys to switch to our extensions. We can at least learn from them. It's a pretty rich environment on VS code. |
As discussed in eclipse-cdt-cloud#47, this patch changes how evaluate requests are handled. Currently, they are handled as GDB commands. The intent of the request is more to evaluate expressions in the target language. This is already what we do when context is 'watch'. This patch makes it so we handle it the same way regardless of the context. A simple test for the evaluate request is added. Signed-off-by: Simon Marchi <[email protected]>
* Change behavior of evaluate request handling As discussed in #47, this patch changes how evaluate requests are handled. Currently, they are handled as GDB commands. The intent of the request is more to evaluate expressions in the target language. This is already what we do when context is 'watch'. This patch makes it so we handle it the same way regardless of the context. A simple test for the evaluate request is added. Signed-off-by: Simon Marchi <[email protected]> * Quote expressions passed to -var-create Creating variable objects from expressions containing spaces (such as "2 + 2") does not work currently. Quote the expression passed to -var-create to handle this use case. Signed-off-by: Simon Marchi <[email protected]> * Send error message if evaluate is missing frameId We currently don't support evaluating requests that lack a frameId (normally, we should evaluate them in the global scope). Instead of sending back that the request has succeeded with an error message as the value, return an error. Otherwise, the client doesn't really have a way to notice the failure, since what it receives looks like a regular value. Signed-off-by: Simon Marchi <[email protected]> * Send error when evaluate fails When processing an evaluate request with an invalid expression (such as "2 + "), we send back a "success" with an error message in the body. This doesn't let the client handle the failure correctly. Instead, send back an error. Signed-off-by: Simon Marchi <[email protected]>
|
I am trying to use the cdt-gdb-adapter as part of theia's cdt-gdb-vscode plugin. I can open Theia's debug console and interact with GDB. I think evaluateRequest in GDBDebugSession.js is called when a command is typed in the debug console. Unfortunately all commands send to evaluateRequest seem to be handled as evaluation of variable expressions. So it is not possible to execute arbitrary GDB commands. In the following issue microsoft/vscode-cpptools#106 they solved this by implementing a special prefix command (use "-exec") when executing GDB commands. Is there any way of executing GDB commands directly? |
|
If you are working on Linux, you can set the |
|
The worked great! |
|
This was resolved in #69 - if there is follow-on work, new issues that explain what is left should be raised. |
I looked at the implementation of the
evaluaterequest (specifically thereplcontext), and have some concerns. My understanding is that the goal of this request is to evaluate an expression in the language you are debugging, and not executing debugger commands. In a REPL such as the browser console, you input expressions that can be evaluated as javascript (such as1 + 2), and the debugger returns the result.The current implementation executes the expression as a debugger command, which is not the same thing. My understanding is that this allows to get a really basic gdb console in VSCode, leveraging the debugger console.
I think it would be very useful to let clients evaluate expressions in the language being debugged (e.g.
&myArray) and return the result. This would map pretty much directly to-data-evaluate-expressionin GDB.If it's still needed to run arbitrary GDB commands, we could add another context, but keep repl for evaluating C/C++ expressions. In the long run, it will be much better to have an actual GDB console (#30) anyway.
Comments?
The text was updated successfully, but these errors were encountered: