[Feature Request] Execute GDB commands without typing "-exec"

[xiaochuanyu]

Is there a way to execute GDB commands without typing "-exec".
I find having to type "-exec" as a prefix to every GDB command cumbersome.
Perhaps a flag in the settings can be added to specify all commands in the GDB prompt to be interpreted as GDB commands only. This way there is no need to prefix GDB commands with "-exec".

[filipsky]

I know this is not an answer for your question, but you may find this usefull:
You can add your setup commands in the launch.json in this way (without -exec):

            "linux": {

                "MIMode": "gdb",

                "setupCommands": [

                    { "text": "-enable-pretty-printing", "description": "enable pretty printing", "ignoreFailures": true },

                    { "text": "handle SIGPIPE nostop noprint pass", "description": "ignore SIGPIPE", "ignoreFailures": true }  

                ]
            },

[DanPartelly]

Given the fact that the debugger GUI in Visual Studio code is still quite primitive and does not provide anything more than the basics, one still has to use native debugger commands in console quite intensely for non-trivial debugging. (really, even if you would have enough features in debug UI to rival Visual Studio debug commands would still be necessary IMO)

Having to prefix a native debugger command with -exec is very cumbersome and greatly diminish the speed of ones work.
More than this, it appears to me that the existence of -exec cannot be motivated in any way. First of all, the debugger command window offers all the context you needs, you are only expected to type debug commands there.
Second, if -exec is needed for some esoteric reason , just build a new string yourself behind the scenes. Or if this would interfere with debugging in other modes/languages provide a configuration flag
in the debug settings json and build it only when it is set. Please spare C/C++ users of this pain

[WardenGnaw]

The purpose of VSCode Debug Console is to evaluate expressions. In order to allow users to access more advanced features of gdb, we utilized the Debug Console to also communicate with GDB. To allow us to differentiate a GDB command vs an actual expression, we added the -exec prefix.

[xiaochuanyu]

Alternatively, what about having the concept of different modes in the Debug Console?
I imagine an interface like this in the console:

\gdb
< can now enter gdb commands without -exec >
\exit
< back to normal >

There could even be a indicator in the UI to show what mode you are currently in.

[DanPartelly]

I assume you mean evaluate JS expressions. That all OK when you develop JS and totally inappropriate when you develop native (or really anything else than JS) code of any kind. I would go as far as saying your current design is broken:

1. When you are in a C++ project with cpptoools extension active you are by definition debug C++
   2.You do not want to evaluate expressions in any other language than C++ . The evaluation of those kind of expressions is done through the debugger.
2. In a debugger console interactions one does not expect anything else than debugger commands to work. But it does expect said debugger commands to work.
3. The combination of a C++ mode active in editor (i.e editing recognized C or C++ files) or executing a debug task of type gdb/lldb and a C++ debug extension is enough to offer context . When such a combination is native , by design, you should assume that the user do not wants to evaluate JS, but to interact with the native debugger and evaluate expressions through it. Visual Studio Code evaluations cannot evaluate if ( LLVM::Whatever->Whatever && $rax && *$rsp == whatever )
4. VS studio code C++ debugging UI is not very useful as it is. The only good thing about it is the variable display wich recurses down on complex data types, and the convenience of setting simple breakpoints Visual Studi style.
5. One has to relay extensively on native debugger commands for more advanced debug sessions . Having to type -exec breaks:
   -- years of habits of using debugger commands . You forget it and you curse and it takes you out of the flow. This is killing user attention to the problem at hand. This is a capital sin
   -- even if I would learn to prefix with -exec my debugger commands, why should I do that ? There is no reason in the 7 kingdoms.
   -- speed of typing relevant commands
   -- one key commands , such as (RET) which simply repeats last command
   -- killing one key commands kills efficiency
   -- POLA (evaluating JS when debugging C/C++ whatever, really who has such bright ideas )
   -- orthogonality
   -- respect for economy of typing

I could go on but I think your current design is broken. That window should be context sensitive. i.e when having a native debugger attached it should accept native debugger commands. And all this is one string concatenation away.

Please reconsider the design and make it work for the user, and not against him. As it is now, console gdb/lldb takes you further faster than dancing in VS Code. Context is king, and you really do have enough context to make this happen

[karwa]

It would be nicer if the discriminator was shorter, like >/@/? instead of -exec.

Consider that GDB/LLDB match prefixes (e.g. reg r invokes register read, fr v invokes frame variable) and other commands are tightly abbreviated (bt for backtrace), so developers are used to writing short commands.

I could live with a single character. -exec is too awkward.

[DanPartelly]

Frankly, I do not think is about competition, or mimicking it. It is plain and simple: do you support C/C++ debugging or not. Nobody in their right mind wants to type any type of prefixes when doing native debugging. The debugger integration should work for the user , not against it. As it is today C/C++ debugging is gimped into oblivion. When you debug native code you do not care about evaluation of JS/whatever else.

Whats even worst is that there are no technical reasons to work as it does, so it must be some headstrong person on this team who insists he must be able to evaluate JS when debugging C++ with gdb, using a broken design and in effect ruining it for everybody but himself

[segevfiner]

Does it really evaluate JS?! I think it's supposed to evaluate a C/C++ expression, like the gdb print command. But I don't have a C/C++ project available to test this right now.

[DanPartelly]

well i tried again today , and I was able to evaluate c/cpp expressions . When I tried first time, no, nada, not even $rax. its ok as it is now

[DanPartelly]

It works in the sense I am now able to directly eval C/C++ expressions , not typing GDB commands . try something like $rax to eval content of rax register or try to dereference a pointer, it should work. Its not perfect , but at least evals native

[pieandcakes]

@DanPartelly @9527KGG Thanks for continuing the conversation. The debugConsole is owned by VS Code. All entries typed into that box are sent to the extension as an EvaluateRequest with a context of repl. This allows users to evaluate an expression quickly without adding the item to the watch window.
The protocol reference is here.

We added -exec to allow differentiating commands sent by the user that are to be redirected to be a gdb command instead. I think the comment here is valid and we can look at adding a single key that is meaningless outside of this context.

[rlivings39]

This would be great to resolve as I've also found the need to type -exec frustrating. For now my workaround has been to add a keyboard shortcut in the debug console to insert "-exec ":

{
    "key": "ctrl+alt+e",
    "command": "editor.action.insertSnippet",
    "when": "inDebugRepl",
    "args": {
      "snippet": "-exec "
    }
}

That way Ctrl+Alt+e just inserts it for me.

[kgfly]

Wow, this is a very cool workaround. It works for me. Thanks!

[martijnthe]

Having prepend all GDB console commands with -exec also confused me.

We added -exec to allow differentiating commands sent by the user that are to be redirected to be a gdb command instead. I think the comment here is valid and we can look at adding a single key that is meaningless outside of this context.

Would it be possible to flip it around and by default treat the input as GDB commands, except when the input starts with -no-exec?

[Makogan]

Trying to revive this thread. I also find it extremely annoying to type the characters and I am not satisfied with having to do a work around by maping it to a shortcut.

Also, can we get variable autocompletion when pressing tab? Please?

[penagos]

I would also find this fix to be extremely useful. Some sort of setting we could toggle to directly pipe commands to GDB and not to the VSCode REPL interface. Or allow extensions to override this.

[pieandcakes]

I think the last suggestion that was easy to implement would be to offer an alternative to -exec by using the ` character.

would that be sufficient to get around this issue? The setting idea would require more work and probably wouldn't happen as quickly.

@Makogan

Also, can we get variable autocompletion when pressing tab? Please?

I'll see if there is a separate feature request for this and if not, i'll create one.

[penagos]

Having the ` character as an alternative in the interim would certainly help but I'd still like to see some mode where we could directly talk to the debugger without prefacing commands (whether or not that entails adding a setting for the current debug console to differentiate between evaluating expressions in the target lang/debugger or providing a mechanism for debugging extensions to create and fully control their own console). This is one of the largest pain points for me when using this extension.

[segevfiner]

I think this is the way that it is because the debug adapter protocol (DAP henceforth) only supplies a request for evaluating an expression in the debugged language. The debug console is hardwired to use that request and has no clean way to expose alternative command lines, such as the debugger's own CLI.

It stands to reason that the -exec hack is the best whoever developed it could come up with to quickly support it, since unlike some other debuggers, access to the debugger's own command line is quite important for GDB/WinDBB.

A clean solution would need to see the DAP expanded to support exposing alternative CLI inputs, and VS Code's UI expanded with the appropriate widget to input them (Such as a combo selection between an expression or a debugger command in front of the debug adapter input box).

[Makogan]

I agree with what @penagos said,the ` character is certainly better than -exec, but it's still infinitely many more characters than not typing anything. Of course, beggars can't be choosers, if the ` character is the only feasible solution I'll be satisfied, but in an ideal world, using the integrated debug mode as one would a regular terminal for GDB would be a dream come true.

[pieandcakes]

@Makogan In a perfect world we would be able to tell the difference between an Eval request and a repl call within the debug adapter but with the way it was designed, we don't know this at all at the layer where we communicate with gdb. To change the behavior to allow for it to be a direct gdb terminal would require a major refactoring.

[penagos]

@pieandcakes thanks for adding support for `. Instead of modifying the debug console to directly communicate with GDB would it be just as much work to invert what is classified as a debugger command? I.e. if I toggle invertREPLExec, <command> now maps to the debugger, and -exec <command> is evaluated as a REPL call? I personally never use the debug console to evaluate expressions (in C++). Instead I exclusively use it to interface with GDB.

[pieandcakes]

Yes, because in the depths of MIEngine it ends up going down the same evaluation path as normal watch windows because by design, this was supposed to be similar to a watch window request. As such, at the protocol level we don't have a good way to issue direct commands to the debugger and since it goes down the same path as a watch window request, there isn't a good way to invert the commands either.

I looked into it as i thought it would be an easy item to add a flag and just flip it but because the bottom layer in MIEngine (which converts AD7 to MI) doesn't expose gdb commands to the upper layer (VS Code debug protocol to AD7) we don't have a way to do that today. It would be a major undertaking that we can take as a feature request but not something I can get out quickly as it would require extensive testing across our VS Code and VS surface area.

[penagos]

I see; in looking at the interface between AD7/VSCode it does appear that the mechanism used to implement -exec requests, as you stated, was to extend the variable evaluation request, so hijacking that request likely isn't trivial. It would be great though if this could be considered on a future release!

[Lectem]

I also had this issue, and it makes it is really hard to discover that you need --exec or ` for commands.
Wouldn't it be possible to at least show text in the background of the menu that says something along the lines of

evaluate expression (prefix with ` or --exec" for gdb commands)

When the current debugger is gdb/lldb/windbg or whatever debugger needs it ? Because right now it's not only unpractical, but very confusing.

I know there's already a message Execute debugger commands using "-exec <command>", for example "-exec info registers" will list registers in use (when GDB is the debugger) but it can get burried in the output. And I for one, didn't even see it as I thought it was just the usual gdb output (same color as any symbol loaded). I think the message should be in the command widget instead.

A (imho) better thing would look like this:

I find the first experience with debugging in VScode for people who never used it to be very misleading.

[pieandcakes]

@Lectem Do you know if this is something that VS Code supports and we don't have it implemented? I can do some research when i have time.

[Lectem]

@Lectem Do you know if this is something that VS Code supports and we don't have it implemented? I can do some research when i have time.

I honestly have no idea, but if it doesn't support it, it should!

[astrosmurfen]

I extended the approach of rlivings39 above a bit by using the multi-comman extension
https://github.com/ryuta46/vscode-multi-command
By doing this I added inserting -exec tight after sending each command to gdb

To do this install multi command,
Add this to settings.json

"multiCommand.commands": [
    {
        "command": "multiCommand.enterExec",
        "sequence": [
            "repl.action.acceptInput",
            {"command": "editor.action.insertSnippet", "args": {"snippet": "-exec "}}
        ]
    }
]

and this to keybindings.json

{ 
  "key": "enter", 
  "command": "extension.multiCommand.execute" , 
  "args": { "command": "multiCommand.enterExec" },
  "when": "inDebugRepl"

}

Pressing enter to submit a command to gdb will now add -exec to the command prompt in preparation of the next command

[hliu202]

I extended the approach of rlivings39 above a bit by using the multi-comman extension
https://github.com/ryuta46/vscode-multi-command
By doing this I added inserting -exec tight after sending each command to gdb

To do this install multi command,
Add this to settings.json

"multiCommand.commands": [
    {
        "command": "multiCommand.enterExec",
        "sequence": [
            "repl.action.acceptInput",
            {"command": "editor.action.insertSnippet", "args": {"snippet": "-exec "}}
        ]
    }
]

and this to keybindings.json

{ 
  "key": "enter", 
  "command": "extension.multiCommand.execute" , 
  "args": { "command": "multiCommand.enterExec" },
  "when": "inDebugRepl"

}

Pressing enter to submit a command to gdb will now add -exec to the command prompt in preparation of the next command

Great! This is the best solution currently. Life is easier.

[xiongqr]

Have a related question, how to redo last command in debug console? I am using Mac and the arrow keys do not work. Thanks

[ThomsonTan]

For using ` discriminator in debug console, there is one potential downside. I installed some extension (don't know which one it is for now), which automatically appends another ` after my input (probably it is assumed as string wrapper), then I need 2 other key strokes to delete the auto inserted "`" before typing command for gdb.

[LinHeLurking]

I think we can have an option to switch the debug console between "GDB command mode" and "normal mode", just like what the extension CodeLLDB does.

[ls89757]

For using discriminator in debug console, there is one potential downside. I installed some extension (don't know which one it is for now), which automatically appends another after my input (probably it is assumed as string wrapper), then I need 2 other key strokes to delete the auto inserted "`" before typing command for gdb.

Maybe you are typing ` in a json file, such as the lauch.json file, however there is no auto insert ` in C/C++.

[Trass3r]

No he's talking about the debug console. Same for me, 2 ` get added sometimes when you press.

[tfuto]

Simple solutions:

• Add a checkbox on the GUI to indicate that anything typed will be transparently forwarded to GDB, or
• Support a simple command, e.g. set gdbmode true, that turns on transparent forwarding all further commands and keystrokes to GDB.

Anyone who thought that -exec is a workable solution probably never debugged with GDB seriously for longer than 10 minutes. ENTER key correct behavior,s, n characters without any prefix are mandatory.

Also, when debugging with GDB, you must not steal focus from the command edit box to the current line in the source. We do: s, ENTER, ENTER, ENTER, n, ENTER, ENTER, s, n, ENTER, ENTER, ENTER, ENTER. After each GDB command I have to click back to that narrow edit box where the command can be entered. There is no shortcut to put the focus back there.

(Also, interactive debug usually involves a lot of script execution, and we need to source scripts left and right, directly into GDB.)

[ilyaZar]

Yes 💯 agreeing to @tfuto . The user experience when debugging currently is horrible...

Using ' made it slightly better but anyone who works a lot with C++ would consider this a temporary workaround at most.