I was trying to debug a c++ program in Code::Blocks, but it didn't work and gave me this message: "ERROR: You need to specify a debugger program in the debugger's settings.
(For GCC compilers, it's 'gdb' (without the quotes))"
When I opened the debugger settings, I found the debugger path empty and don't know what its path.
Anyone has an idea about where can I found the debugger file.
Note: I use Manjaro Linux
The Error appeared because I hadn't installed the GDB, after I install it the debugger path automatically set as "/usr/bin/gdb".
Related
I'm having problems debugging Rust programs with LLDB on windows.
LLDB doesn't seem to be able to find the PDB file, even though it's in the same directory as my binary.
I run LLDB from the command line on my binary and no luck.
I also tried using the --symfile option of the debuggers file command and it still won't display any debugging info.
Any ideas?
I'm using Visual Studio Code to (try to) debug my node.js scripts. On the moment I want to debug my index.js file, Visual Studio Code says 'Cannot find runtime 'node' on PATH. Is 'node' installed?
And the answer to this question is 'yes', because it can be found in my 'usr/local/bin' folder. And when I execute the commando 'echo $PATH' in my bash terminal, then I see this path is included (among others):
echo $PATH
/opt/local/bin:/opt/local/sbin:/Users/{myName}/anaconda3/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
Have also done some google searches on the issue but haven't been able to find a sound solution.
Can you please help?
Hans
For background info: I have installed Visual Studio Code via Anaconda and I'm using a Mac on 10.13.6 (MacOS Sierra).
I rather hoped there would be an answer better than the one I am about to give. For me over on Ubuntu 19.04, going through the install process for node fixed the issue; in my case, the PATH variable on my system was correct, and everything in ./.vscode/launch.json was correct. Defeated, I decided to reinstall node, and suddenly debugging worked despite the PATH being exactly the same afterwards. Never thought I would be debugging my debugger!
I am having issues compiling this project on zephyr.js, the instructions on their GitHub are for Linux however they do have an environment setup for Windows as well which I have completed to the letter.
When I run the compilation using the makefile I get:
CMake C:/IntelSWTools/ISSM_2016/tools/compiler/gcc-ia/5.2.1/bin/i586-intel-elfiamcu-gcc is not a full path to an existing compiler tool.
I am using the msys terminal with MinGW and I have installed CMake separately and configured it... but why is it throwing this error? I have checked, and the file is actually there. If I type C:/IntelSWTools/ISSM_2016/tools/compiler/gcc-ia/5.2.1/bin/i586-intel-elfiamcu-gcc. into the terminal, it also executes the compiler successfully.
Any ideas?
(Before anyone tells me to try on Linux, for now, it is a requirement to use Windows for this project)
I am running Xubuntu on a 64 bit machine. When trying to debug a Beaglebone using gdb (via Eclipse) I get the following error message:
"Remote 'g' packet reply is too long"
See here for more details:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509479
At the host I am using gdb-multiarch.
When start it, it announces:
"This GDB was configured as "x86_64-linux-gnu"."
Can you please tell me how to configure GDB to work with a 32 bit target? Any other thoughts?
Thank you.
As far as I know the BeagleBone uses an ARM processor.
You'll have to get the ARM version (more precise: version for debugging ARM processors) of GDB to debug - you cannot do this with the x86 version.
For Windows the ARM version is available in the "WinARM" packet.
Maybe for Linux such a packet does not exist and you'll have to re-compile GDB.
Add "set architecture arm" to the .gdbinit file referenced in Eclipse under Debug Configurations -- Debugger -- GDB command file. Make sure the .gdbinit file can be found at run-time by making sure GDB command file contains full path to file.
I encountered a similar issue trying to set up cross compilation through Eclipse with a Ubuntu 12.04 Host VM running on a Mac connecting to a Beaglebone Black target. When trying to debug my project, I would get the same "Remote 'g' packet reply is too long" error. What solved this issue for me was to go into the Debug Configuration for your project, select the Debugger tab, and replace gdb to gdb-multiarch the GDB debugger field.
In short, I need to understand how to configure eclipse to run "optirun gbd" instead of "gdb". An explanation of what exactly I'm trying to accomplish follows.
I need to run my debug app in eclipse such that it will use the nvidia optimus card instead of the integrated card. My app requires opengl support that is only available this way.
I've got a laptop with an nvidia optimus video card. I'm running linux (ubuntu). I've successfully set up bumblebee such that I can take advantage of the optimus technology. This requires that, to use the nvidia card, I run a given program "foo" with the program "optirun:" optirun foo.
I need to configure eclipse to launch my program in debug mode under optirun. If I run from command line: optirun gdb app everything works as expected.
Edit: Changing the "GDB Debugger" field inside the debug configuration to optirun gdb does not work. Lanching eclipse by optirun eclipse does, however. But this is a detriment to battery life.
Go to "Debug Configurations", open "Debugger" tab. Change "GDB debugger" from gdb to optirun gdb.
Works in Eclipse Juno, Ubuntu 12.04.
Since I'm sure eclipse uses the shell to execute the program, a workaround is to alias gdb to optirun gdb in ~/.bashrc
I look into this issue today and I found another solution. As long as you have Bumblebee installed (http://www.bumblebee-project.org/) and you know you can attach optirun to an executable (try with glxgears for example) you can attach it to cuda-gdb.
What I did is create a script:
#!/bin/bash
optirun /usr/local/cuda/bin/cuda-gdb $*
And save it to /usr/local/cuda/bin or somewhere else it doesn't matter, with the appropriate permissions for execution (755).
What it does is very simple, it runs optirun cuda-gdb args where args is whatever the command line sends it.
In terminal just run opti_cuda-gdb with or without arguments.
For example I named it opti_cuda-gdb and placed it in that directory (which conveniently is added to the path if CUDA is properly configured).
If you use an IDE to develop, like say Netbeans, point the debbuger executable to that script.
I've been successfully compiled and debbuged code using CuSparse and CuBlas with NetBeans running in a SAMSUNG SF410 with Nvidia Optimus and Ubuntu 11.04 and 11.10.
I'm open to provide further details if you think I omitted something.