penagos / vgdb Goto Github PK

Every time you enter an invalid command in the debug console a new message pops up and thats really annoying

Hey, I noticed a strange behavior of the plugin on vscode version 1.67.1 (prior to this ver. it was OK). Instead of running in the dedicated "debug console" pane the session starts in the built in terminal. What's more, the debugging stops immediately and you have to input "run" to move forward. Variables and call stack views are empty, the debugging toolbar allows only for stopping or restarting (pause button is inactive). I haven't changed my lauch.json. My config:

    {
        "type": "vgdb",
        "request": "launch",
        "name": "C/C++ Debug Launch - vGdb",
        "program": "${command:cmake.launchTargetPath}",
    },

how to use vgdb remote debug? like cpptoos miDebuggerServerAddress

I noticed this at first when I set did set logging on in the startup commands, and found gdb.txt in the directory vscode was launched from... not alongside the executable.

I tried hardcoding a cd command into the generation of the gdb launch, here:

So just doing cd /path/to/debuggee/ ; at the beginning of the executed string, before the $.

When I did that, it not only put gdb.txt in a better place, but made other things work that weren't. I'd been getting messages from gdb of "No source file named..." on paths that did exist. But it turns out that message really means "Couldn't find symbols for file named...". By launching gdb in the directory where the output executable was (instead of where vscode was launched) these errors went away.

After doing this I was able to debug chromium built from source. And vgdb does not seem to have problems watching Blink::Node variables (which causes vscode-cpptools to hang),

When I try to pause specific thread listed in the "Call Stack" by clicking on the pause mark next to the thread listed, there are no response.

This is an example. When I click on the pause button, the thread does not pause.

Hi thank you very much for developing this great extension! It's working so nicely 😄

One question is that, is it possible to pass gdb CLI options from vgdb?

In my use case (debug of MariaDB), I need to pass -x option to execute startup commands from a file, like the below command:

gdb -x /home/ec2-user/MariaDB-server/bld/mysql-test/var/tmp/gdbinit.mysqld.1   /home/ec2-user/MariaDB-server/bld/sql/mysqld

Because the content of gdbinit.mysqld.1 won't dynamically change, currently I'm copy and pasting the content to startupCmds option in launch.json as a workaround. But ideally it can be passed by -x option.

Is there any way already implemented to achieve this? Thanks!

I'm attempting to debug vgdb by comparing back and forth with cpptools. This would be easier (and easier adoption in general) if the settings and formats used in launch.json were the same.

(Any improvement that a change like calling the debugger path "debugger" vs. "miDebuggerPath" is far outweighed by having it be different!)

For reference, here's their launch.json documentation:

https://code.visualstudio.com/docs/cpp/launch-json-reference

Please make this extension available to Open VSX marketplace, this will also make it directly available for VSCodium and Gitpod.

Open VSX is a vendor-neutral open-source alternative to the Visual Studio Marketplace. It provides a server application that manages VS Code extensions in a database, a web application similar to the VS Code Marketplace, and a command-line tool for publishing extensions similar to vsce.

There is a guide for publishing and after the initial setup it is just a matter of osvx publish (similar to the MS marketplace).

If wanted then there are github actions that can publish to both marketplaces on tagging.

Hey

I get

    \`tty\`: No such file or directory.

on every startup. My launch.json:

{
            "type": "vgdb",
            "request": "launch",
            "name": "C/C++ Debug Launch - vGdb",
            "program": "${command:cmake.launchTargetPath}",
            "debug": "verbose"
        }

DEBUG CONSOLE output:

Reading symbols from /home/iwasz/workspace/liboledgui/build/ncurses...
1^done,register-names=["rax","rbx","rcx","rdx","rsi","rdi","rbp","rsp","r8","r9","r10","r11","r12","r13","r14","r15","rip","eflags","cs","ss","ds","es","fs","gs","st0","st1","st2","st3","st4","st5","st6","st7","fctrl","fstat","ftag","fiseg","fioff","foseg","fooff","fop","xmm0","xmm1","xmm2","xmm3","xmm4","xmm5","xmm6","xmm7","xmm8","xmm9","xmm10","xmm11","xmm12","xmm13","xmm14","xmm15","mxcsr","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","fs_base","gs_base","orig_rax","al","bl","cl","dl","sil","dil","bpl","spl","r8l","r9l","r10l","r11l","r12l","r13l","r14l","r15l","ah","bh","ch","dh","ax","bx","cx","dx","si","di","bp","","r8w","r9w","r10w","r11w","r12w","r13w","r14w","r15w","eax","ebx","ecx","edx","esi","edi","ebp","esp","r8d","r9d","r10d","r11d","r12d","r13d","r14d","r15d"]
2^done
3^error,msg="The program is not being run.
Warning: 'set target-async', an alias for the command 'set mi-async', is deprecated.
Use 'set mi-async'.
4^done
`tty`: No such file or directory.
5^error,msg="During startup program exited with code 1.

And the OUTPUT pane with vGdb selected:

-data-list-register-names
1^done,register-names=["rax","rbx","rcx","rdx","rsi","rdi","rbp","rsp","r8","r9","r10","r11","r12","r13","r14","r15","rip","eflags","cs","ss","ds","es","fs","gs","st0","st1","st2","st3","st4","st5","st6","st7","fctrl","fstat","ftag","fiseg","fioff","foseg","fooff","fop","xmm0","xmm1","xmm2","xmm3","xmm4","xmm5","xmm6","xmm7","xmm8","xmm9","xmm10","xmm11","xmm12","xmm13","xmm14","xmm15","mxcsr","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","fs_base","gs_base","orig_rax","al","bl","cl","dl","sil","dil","bpl","spl","r8l","r9l","r10l","r11l","r12l","r13l","r14l","r15l","ah","bh","ch","dh","ax","bx","cx","dx","si","di","bp","","r8w","r9w","r10w","r11w","r12w","r13w","r14w","r15w","eax","ebx","ecx","edx","esi","edi","ebp","esp","r8d","r9d","r10d","r11d","r12d","r13d","r14d","r15d"]
-exec-interrupt 
2^done
-exec-continue
3^error,msg="The program is not being run."
-gdb-set target-async on
4^done
-exec-run
5^error,msg="During startup program exited with code 1."
-thread-info
6^done,threads=[]
-thread-info
7^done,threads=[]

As a workaround I can edit GDB.js and change `tty` to like /dev/pts/5 and the output of my program goes there.

For a brief moment after starting the debugging I can see this line on the console :

    /usr/bin/env gdb --interpreter=mi -q --tty=\`tty\` --args PATH_TO_MY_EXEC < /tmp/vGDB_InRandomstring > /tmp/vGDB_OutRandStr

I'm on Manjaro Gnome, my default shell is zsh, but vscode is configured to use bash. vscode versio 1.68.1

I am trying vgdb on this simple example case in vscode-cpptools issue 5235 (as I had it on hand from looking at that debugging issue...)

vgdb didn't work--just hung, not hitting the breakpoint. So I decided I'd try building the vgdb extension and seeing if I could figure out why not.

However once I started running vgdb under extension debugging it did occasionally work. Then I found that I could get it to always work by setting a breakpoint on the call to new IntegratedTerminal(launchCommand, terminal);...then stepping over it...then hitting continue.

Looking in the running processes list it doesn't seem new IntegratedTerminal alone has started gdb either way. But having the delay introduced by debugging at that point does seem to make the difference between whether it works out later or not. When it is the hung state, there is no gdb process started when looking in the processes with ps--but it thinks it has sent several commands and is in a state of waiting for a response. (The successful state obviously has a gdb process started.)

I thought to try changing to externalConsole: true so it doesn't make an IntegratedTerminal. In doing so, I don't have to disrupt the timing via a breakpoint to get it to work.

(Sidenote: once I got vgdb to run, it also manifests issue 5235 for the same reasons)