I'm currently developing a (simple) kernel using Qemu for i368.
I was using a normal makefile and had debugging via GDB into Qemu working perfeclty
The I moved to CMake and for some reason I can only hit breakpoints when my code is already in a breakpoint.
I also can't pause, the feedback I get from the debug window is the pause was succesful
When setting a breakpoint it tells me Attempting to bind the breakpoint
A hint may be that when I stop the debug session, I get a popup from vscode saying timeout
My launch.json
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Launch with GDB",
"type": "cppdbg",
"request": "launch",
"program": "${command:cmake.launchTargetPath}",
"cwd": "${workspaceRoot}",
"args": [],
"targetArchitecture": "x86",
"MIMode": "gdb",
"miDebuggerPath": "/bin/gdb",
"miDebuggerArgs": "",
"logging": {
"trace": true,
"traceResponse": true,
"engineLogging": true
},
"customLaunchSetupCommands": [
{
"text": "target remote localhost:1234",
"description": "Connect to QEMU remote debugger"
}
],
"setupCommands": [
{
"text": "file ${command:cmake.launchTargetPath}",
"description": "Load binary."
},
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
}
]
}
Pause response
<-- C (pause-67): {"command":"pause","arguments":{"threadId":1},"type":"request","seq":67}
--> R (pause-67): {"type":"response","request_seq":67,"success":true,"command":"pause","body":{},"seq":1321}
Response when setting a breakpoint:
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (340258) Send Event AD7BreakpointErrorEvent\n"},"seq":1327}
1: (340258) Send Event AD7BreakpointErrorEvent
--> R (setBreakpoints-69): {"type":"response","request_seq":69,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":4,"verified":true,"line":73}]},"seq":1329}
--> E (breakpoint): {"type":"event","event":"breakpoint","body":{"reason":"changed","breakpoint":{"id":4,"verified":false,"message":"Attempting to bind the breakpoint....","line":73}},"seq":1331}
If I type stop in Qemu terminal then vscode stops and I can set breakpoints again.
I have the same issue and still haven't solved yet.
But I found something maybe useful for you.
according to their discussion under this issue: https://github.com/Microsoft/vscode-cpptools/issues/833
you can try
set target-async to off for your debugger:
"setupCommands": [
{
"text": "set target-async off"
}
send SIGINT to your local debugger process
-exec -interpreter-exec console "signal 2"
to see if it can pause or not.
I meet the similar issue, try to connect remote target with option ""MIDebuggerServerAddress": "targetIp:port", not command in customLaunchSetupCommands.
Related
I can:
Start the debugger and it attaches to my remote application
Hit breakpoints in the main process
Visually step through the code using vscode
I can't (help required):
Hit breakpoints in child process after a fork()
I added some setup (setupCommands) for gdb in my vscode launch.json that should allow child process debugging
{
"version": "0.2.0",
"configurations": [
{
"type": "gdb",
"request": "attach",
"name": "Debug - MyHost",
"gdbpath": "/usr/local/bin/gdb",
"target": "MyHost:1234",
"remote": true,
"stopAtEntry": true,
"setupCommands": [
{ "description":"In this mode GDB will be attached to both processes after a call to fork() or vfork().",
"text": "-gdb-set detach-on-fork off",
"ignoreFailures": true
},
{ "description": "The new process is debugged after a fork. The parent process runs unimpeded.",
"text": "-gdb-set follow-fork-mode child",
"ignoreFailures": true
}
],
"cwd": "${workspaceRoot}",
"valuesFormatting": "parseText",
}
],
}
The breakpoints in the child process, after a fork(), were not hit as expected.
Fork spawns a new process. You are debugging the original process, not the fork.
To debug the fork, you will have to attach to the pid of the new instance.
I'm working on an ESP-IDF based project that runs on ESP32 microcontrollers.
The project has a bunch of different C++ libraries (ESP-IDF calls them components) I've written. Normally I compile the whole project and it gets installed on the ESP32, and everything works great.
I've been writing tests, and how I make the tests work is a little different than the standard build process. For each set of tests, I am testing just one of my C++ components. (for instance "Wireless" or "UserInputs", etc) I mock out the rest of my components and the ESP-IDF code that my code uses, and this lets me just test "Wireless", for instance.
To do this, I'm using CppUTest and a series of makefiles. The makefile structure is based on the structure here: https://github.com/memfault/interrupt/tree/master/example/unit-testing/minimal
And here's the article I followed that is describing that makefile/testing setup.
https://interrupt.memfault.com/blog/unit-testing-basics#setting-up-cpputest
So, there's a main makefile, and it finds all the per-component makefiles. Those per-component makefiles specify which .cpp files to compile, what folders to find your imports in, where your tests are, etc. And all that works great.
The situation I'm in is that I want to be able to run the debugger in VSCode to set breakpoints, pause execution, and inspect my variables at a given point in my code.
Just doing this in the tests is enough. I don't need debugger in my main ESP-IDF build process.
But I'm having the most challenging time working with this kind of setup. Because there's not just ONE make file.
Here's the core of what I want to do. I want to be able to set a breakpoint, and then do something to tell my code to compile with a given list of .cpp files, and header import locations. Just like in those per-component test make files. And I want my code to execute to that breakpoint and then give me the sauce in VSCode.
Any suggestions on how I can work in this direction would be very helpful.
I was able to work this out. Here's what I did...
Firstly, I ran my tests. Now when I look in unit_tests/build/ I see sub
folders for each make file. And in those subfolders there are executables. For instance, unit_tests/build/data/data_tests
I made a .vscode/launch.json file in my repo. It's looks like this...
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch for Dispatch Component",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/unit_tests/build/dispatch/dispatch_tests",
"stopAtEntry": false,
"cwd": "${fileDirname}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
},
{
"description": "Set Disassembly Flavor to Intel",
"text": "-gdb-set disassembly-flavor intel",
"ignoreFailures": true
}
]
},
{
"name": "(gdb) Launch for Wireless Component",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/unit_tests/build/wireless/wireless_tests",
"stopAtEntry": false,
"cwd": "${fileDirname}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
},
{
"description": "Set Disassembly Flavor to Intel",
"text": "-gdb-set disassembly-flavor intel",
"ignoreFailures": true
}
]
},
{
"name": "(gdb) Launch for Data Component",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/unit_tests/build/data/data_tests",
"stopAtEntry": false,
"cwd": "${fileDirname}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
},
{
"description": "Set Disassembly Flavor to Intel",
"text": "-gdb-set disassembly-flavor intel",
"ignoreFailures": true
}
]
},
]
}
Notice that in that launch.json file there are multiple configurations. One for each component/make file. The name of each configuration says what component it's for, and the program field points to the executable that the tests built.
If I'm in the Data component and want to drop into a breakpoint, here's
what I do.
ensure that there's a test called by the Makefile_data.mk that hits my
breakpoint.
click the Run and Debug button on the left in VSCode. (the bug with the play button)
click the dropdown at the top of Run and Debug and select Launch for Data Component
Hit play.
Now my tests run and when they get to the breakpoint in the code in my Data
component they will pause. Pretty slick!
I'm trying to debug a program, in VSCode, which violates an assert, but doesn't break and doesn't allow me to inspect the callstack or anything. Instead the program just exits with exitcode 3 and prints out the following text:
Assertion failed!
Program: C:\Users\Sewbacca\Projects\Practice\CppTest\build\Test.exe
File: C:\Users\Sewbacca\Projects\Practice\CppTest\src\main.cpp, Line 6
Expression: false
I tried to add the following commands to "setupCommands" in .vscode/launch.json with no success:
{
"text": "break _assert (const char *_Message, const char *_File, unsigned _Line)"
},
{
"text": "break abort"
},
{
"text": "break exit"
},
Sidenote: I'm not experienced with gdb and I don't know exactly what setupCommands does change. I would have expected that vscode send these to gdb directly.
My only workarround is to set a breakpoint before main() and type -exec break abort into the debug console. Then it will break on any failed asserts.
Edit:
Adding the following config to "setupCommands":
{
"text": "-exec break abort"
},
Resulted in following error message:
[Window Title]
Visual Studio Code
[Content]
Unable to start debugging. Unexpected GDB output from command "-exec break abort". Undefined MI command: exec
[Open 'launch.json'] [Cancel]
End of Edit
Is there a way to automate this or is there a proper way to tell gdb (especially in VSCode) to break on failed asserts, rather than just exit the program?
Edit:
There was nothing wrong with my configuration. It seems like my gdb version was buggy. Sometimes it exited randomly when I told gdb to break before entering main, which led me to this issue. As stated there, gdb 8.1 for x86_64-w64-mingw32 has this bug. Since there is no newer version available in the installer, I downgraded to 7.2 which solved this issue for me. However, after using winlibs version 11.1.0, the issue still persists.
End of edit
Thanks in advance!
Setup:
src/main.cpp
#include <cassert>
int main()
{
assert(false);
}
CMakeLists.txt
project(Test)
add_executable(${PROJECT_NAME} src/main.cpp)
.vscode/launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
// Resolved by CMake Tools:
"program": "${command:cmake.launchTargetPath}",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [
{
// add the directory where our target was built to the PATHs
// it gets resolved by CMake Tools:
"name": "PATH",
"value": "${env:PATH}:${command:cmake.getLaunchTargetDirectory}"
}
],
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
},
{
"text": "break _assert (const char *_Message, const char *_File, unsigned _Line)"
},
{
"text": "break abort"
},
{
"text": "break exit"
},
]
}
],
"compounds": []
}
My Environment:
Platform: Windows 10
Toolchain: mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0
Build system: CMake
IDE: VSCode with extension CMake Tools
I found a solution:
gdb breaks on failed asserts, when adding the following code to setupCommands in launch.json:
"setupCommands": {
...
{
"text": "set breakpoint pending on",
"description": "Ensures that a breakpoint for abort will be set!",
"ignoreFailures": true
},
{
"text": "break abort",
"description": "Breaks on failed asserts",
"ignoreFailures": true
},
{
"text": "set breakpoint pending auto",
"description": "Setting back to default behaviour",
"ignoreFailures": true
}
...
}
Explaination:
To break on assert failures, I found this Stack Overflow Post, which worked, when I tested it manually, but not when I used it in launch.json.
I don't understand why it doesn't break on its own, but I do understand why break abort didn't worked, at least I have a guess: The symbols haven't been loaded yet and break abort asks you in gdb, if a pending breakpoint should be created, which defaults to no. So setting pending breakpoints to on, solved this issue for me and now I can finally debug my program.
I have installed Ubuntu 20.04 on my Windows 10 system. Before I first ran VS Code from within Ubuntu, VS Code worked fine in Windows. Now, I can build my C++ app there, but cannot debug it. I get an alert box saying "Cannot find runtime 'node' on PATH. Is 'node' installed?"
Whenever I start VS Code, a background process called 'node' also starts, so I presume VS Code starts it. My Ubuntu installation has about eight versions of node.js in various subdirectories of ~/.vscode-server.
Here is my launch.json:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Launch Program",
"program": "${workspaceFolder}/gametest",
"skipFiles": [
"<node_internals>/**"
]
},
]
}
I tried installing the newest nodejs. I no longer get the alert box with the not found message, but the debug console in VS Code now shows:
/usr/bin/node /home/jon/projects/KSolve/gametest
Debugger listening on ws://127..... (can't copy from debug console window)
For help, ...
/home/jon/projects/KSolve/gametest:1
ELF(three squares)
^
SyntaxError: Invalid or unexpected token
at Module._compile (internal/modules/cjs/loader.js:723:23)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
...
...
Process exited with code 1
Some time ago for me also was tricky to run debugger on VS Code under WSL Ubuntu. With a lot of attempts I have got next .vscode/launch.json file:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "test tree",
"type": "cppdbg",
"request": "launch",
"program": "enter program name, for example ${workspaceFolder}/tests/ttree",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}/tests",
"environment": [],
"externalConsole": false,
"targetArchitecture": "x86_64",
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
]
}
I'm trying to remote debug a c++ app from a VM ubuntu 16.04 amd64 host to a debian armbian target of cubietruck board (ARM® Cortex™-A7 Dual-Core) via vs code.
I have follwed this guide https://medium.com/#spe_/debugging-c-c-programs-remotely-using-visual-studio-code-and-gdbserver-559d3434fb78 with the only addition of the field
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
so the whole launch.json has become
{
"version": "0.2.0",
"configurations": [
{
"name": "C++ Launch",
"type": "cppdbg",
"request": "launch",
"miDebuggerPath": "/home/user/ARM/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
"program": "/home/user/myproject/bin/app",
"miDebuggerServerAddress": "localhost:9091",
"args": [],
"stopAtEntry": false,
"cwd": "/home/user/myproject",
"environment": [],
"externalConsole": true,
"linux": {
"MIMode": "gdb"
},
"osx": {
"MIMode": "gdb"
},
"windows": {
"MIMode": "gdb"
}
}
]
}
in launch.json file so as to support pretty printer.
In the host I'm using the linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf gdb while the gdb in arm board has the native 8.0.1 gdb.
Everything works fine except from the pretty printer since the strings are not shown correctly. Whenever I hover over a string the fields npos and _M_dataplus pop up and one should open the _M_dataplus filed to see the actual string.
In host the linaro gdb supports pretty-printer since the command info pretty-printer gives the output :
builtin
mpx_bound128
However when I give the same command in target gdb 8.0.1, I get:
Undefined info command: "pretty-printer". Try "help info".
I also created a .gdbinit file in my host home folder that contains the enable pretty-printer command. I saw in the debug console that it was executed successfully but the result was erroneous as well.
Since I am pretty novice in remote debugging, what should I do to get the pretty-printer working. Should I install pretty-printer in the remote board as well or am I doing something else wrong?
1.make sure your bin is NOT built with -static-libstdc++
2.if you have to use -static-libstdc++, please add the following in your ~/.gdbinit:
python sys.path.append('/usr/share/gdb/python') <--provided by gdb `show configuration: --with-gdb-datadir=`
python sys.path.append("/usr/share/gcc-8/python/") <--corresponding to your gcc version
source /usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25-gdb.py <--this script is for std::string/list/map/etc pretty-printing.
3.edit your launch.json:
"setupCommands": [
{ "text": "-interpreter-exec console \"set sysroot /\"", "ignoreFailures": true },
{ "text": "-enable-pretty-printing", "ignoreFailures": true },
],
This is what I did to resolve the same issue occured to me. Hope this would resolve your issue.
ref1: http://tomszilagyi.github.io/2018/03/Remote-gdb-with-stl-pp
ref2: http://transit.iut2.upmf-grenoble.fr/doc/gdb-doc/html/gdb/Writing-a-Pretty_002dPrinter.html
ref3: Import Error: No module name libstdcxx