I want to debug my test.out program with the the gdb debugger from mingw. Calling the gdb debugger with the image file is running successful on the terminal window, but every time I started the debugger from eclipse I got the
**Error message from debugger back end:
You can't do that when your target is `None'
Failed to execute MI command:
load C:\Temp\test.out
The gdb commander was configured as path/gdb.exe and image and symbol files are the out file.
In the debugger console view I only see the the information about the installed gdb version simular the output that I got when I type only gdb in the terminal window. No MI command.
Any hints how I can solve my problem or find more informatio about it?
Thanks.
I found the solution, I was too stupid. I configured my debug configuration as gdb hardware debugger, but since it is a c-application, I have to configure it as such one.
Related
I have problems debugging a program in Eclipse 2019-03 using GDB on Windows 10 with MinGW.
Whenever I stop in the program, I get the error message ERROR: Unexpected GDB output from command "-exec-step 1". Cannot find bounds of current function.
I got this also when debugging a new C/C++ project with just printing a line to the console, so it seems unrelated to the actual program that was executing.
Both programs could be debugged fine when running gdb manually on the command line.
Answering my own question: the problem was caused by a number of watch expressions that I had configured in Eclipse. I discovered this when I enabled GDB traces in Eclipse to see the MI commands between Eclipse and GDB.
Removing all watch expressions in Eclipse solved the problem for me.
I need to install debugger in netbeans. I have already installed gdb in the mingw/bin directory with mingw-get.exe install gdb. I have added the line C:\MinGW\bin\gdb.exe. However when i run the debugger it gives out this message:
During startup program exited with code 0xc0000135.
Can anyone explain how to solve this issue?
I think that i have found the solution. I added the line C:\MinGW\bin to the "Path" environment variable (in the control panel) . Now the message error doesnt appear and the debugger is running.
I wish to debug GNU Emacs in Eclipse IDE for C/C++ on my macOS Sierra. I have downloaded the source code with Git and built the project successfully via the command line. I then imported the project to Eclipse as an existing Makefile project with the GNU autotools toolchain setting.
I can now run the Emacs GUI from Eclipse. However, when I try to debug it (with gdb), I get the following error message:
'Launching emacs-26.0.50.1' has encountered a problem.
Error in final launch sequence
Failed to execute MI command:
-exec-run
Error message from debugger back end:
During startup program terminated with signal ?, Unknown signal.
During startup program terminated with signal ?, Unknown signal.
I managed to get rid of this error by specifying the full path to the .gdbinit file in the Run > Debug Configurations... > C/C++ Application > emacs-26.0.50.1 > Debugger > GDB command file: textbox.
I now get a different error, but this is a matter for another question...
I had a similar error message while using the debugger for a small dummy code. I used the suggestion given in this link and got it fixed. In short, I had to change the debugger to an older one. Hope that helps if you are still having the same issue.
The problem for me was using USB 3.0 port. Connected board to USB 2 port and it was working fine.
I have a C++ program that segfaults occasionally. The answer to this SO question provides a way to make GDB run my program over and over until it catches the segfault.
However, navigating my program via GDB has been a pain and I would like to do this using the Eclipse debugger. I have successfully created a debug configuration that runs my program.
Is there a way to make Eclipse keep running this debug configuration until a segfault (or other error) occurs?
I thought I may be able to do it by providing a GDB command file in the debug configuration that would set a break point at the program's exit and then command GDB to rerun the program.
Attempted GDB command file:
break exit
run
end
But using this GDB command file results in the following error when I attempt to start a debugging session:
Error in final launch sequence
Failed to execute MI command:
source /home/matt/gdb-loop
Error message from debugger back end:
/home/matt/gdb-loop:2: Error in sourced command file:\nNo executable file specified.\nUse the "file" or "exec-file" command.
/home/matt/gdb-loop:2: Error in sourced command file:\nNo executable file specified.\nUse the "file" or "exec-file" command.
So it seems like the command for the program I am debugging gets overridden when I modify the GDB command file being used.
FYI: Running Eclipse Neon (4.6.0 build 20160613-1800) on Ubuntu 14.04.
I'm using a Nucleo STM32L031 with AC6 STM32 workbench (eclipse).
I write my application and go to debug mode, everthing was working well until I add another function in my application. I notice that when I remove/comment the "new_function", the software can go to debug mode again. However when I add the "new_function" to the code and go to debug, an error occurs and it cannot go to debug mode.
Error: Error in final launch sequence
Failed to execute MI command:
load C:Project_STM32L031K6-Nucleo\\Debug\\Project.elf
Error message from debugger back end:
Error erasing flash with vFlashErase packet
Error erasing flash with vFlashErase packet
This error does not occur only for this specific "new_function", but also for other functions e.g TIM21_Init() generated by STM32Cube.
I tried to search for the solution, but couldn't find it.
Thanks
Bien
In my case (stm32f429) changing this option helped:
This is an OpenOCD issue, not a problem with your code. I got this issue when the debugger command file was referring to a "stlink-v2-1" but what I actually have is an "stlink-v2". I'm using the STM32F0 Discovery board.
I believe the Nucleo board has the "stlink-v2-1" so you might have the opposite problem as me. Check to make sure that the setting under "Run menu > Debug Configurations > Debugger > OpenOCD setup" is set to the correct debugger.
If a debug configuration file is being used (the "use default script" or "use local script" option is selected) open that file and look for a line like:
source [find interface/stlink-v2.cfg]
In my case the project wizard had created a template that was referencing stlink-v2-1. Changing it to the above fixed the problem.
UPDATE:
I also got this problem when Eclipse crashed and left OpenOCD running in the background. Run
$ ps aux | grep openocd
And if you see an instance of OpenOCD running when the debugger is not, kill it.