I am new to coding and trying to get eclipse neon running on my macbook air. I am having trouble getting the debugger to work. I installed gdb with homebrew, created a certificate and signed gdb as per the instructions in the link:
https://www.ics.uci.edu/~pattis/common/handouts/macmingweclipse/allexperimental/mac-gdb-install.html
I then configured eclipse debugger settings with the location of the newly installed gdb. However now when I try to start the debugger, the initialization process starts but gets stuck forever on 62%. Any tips on how to solve this? Could it be a memory issue? MBA has 4gb RAM...
This is a known bug in CDT - Bug #509737
The problem in summary is that CDT version 9.2.0 cannot work with GDB version 7.12.
One way to resolve this is to use an older version of GDB, for example GDB version 7.11
Another way to workaround this is to pretend GDB 7.12 is actually version 7.11.
Create the following executable script:
#!/bin/sh
if [ "$1" = "--version" ]; then
echo "GNU gdb (Debian 7.11-1) 7.11"
exit
fi
exec /usr/local/bin/gdb "$#"
and configure eclipse to run it instead of gdb.
Related
I've installed (OSX Mojave 10.14.6.) Eclipse CDT and GNU MCU Eclipse plugin and finaly GNU Tools for ARM. My goal is to build and debug ARM code using GDB (arm-none-eabi-gdb).
I've created a Hello World project for Arm, which builds ok - but, debugging seems not to work with GDB (that comes with the Arm package). GDB gets stuck:
I have set the proper paths in Eclipse to arm-none-eabi-gdb.
I have signed the arm-none-eabi-gdb (with the same certificate that I used to sign GDB installed via brew into /usr/local/bin/gdb the day before - and it worked!).
I have also tried running Eclipse as root from command line.
Nothing helps.
The message is "Configuring GDB Aborting configuring GDB".
What to do?
Probably what is going on here is that you built to a given target (ARM based) and you're trying to run it (with gdb) on your mac (x86).
You'll need an emulator or QEMU to properly run on your mac or maybe a real board.
I made my code as a standalone .c file and read that, in order to debug, the file must be in a project. So I made an empty project and added my file to it, set some breakpoints and, when i run the debugger, I get this on console:
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.6.1
Child process PID: 13112
Error in re-setting breakpoint 2: PC register is not available
Error in re-setting breakpoint -3: PC register is not available
In ()
Tried some tutorials and whatched some videos without success. Does somebody knows a fix for that? Is there a simpler way to debug a .c file?
For linux system you could use gdb as debugger in this way:
$ vim hello.c
# include <stdio.h>
int main()
{
printf("hello \n");
}
$ gcc -o hello hello.c
$ ./hello
$ gdb hello
(gdb) break main
(gdb) run
and then you can use:
c or continue
n or next
s or step
For more details see this.
Updated MinGW downloading it from its sourceforge repositor.
Downloaded the 6.2.0 version that is available in this link.
Then I unziped it to C:\ and modified the environment variable Path to add the new C:\MinGW\bin folder. To know if you made it correctly just open CMD and type gcc --version.
After that, I modified the compiller and debugger settings of Code::Blocks to use the new version of MinGW and its executables.
Now it is compiling and debugging properly.
According to Free Pascal's GDB Debugger Tips the problem is with GDB and they cite Bug 14018.
It appears you should use a different version of GDB. They suggest downgrading to 7.2. Now I believe other versions are now available, like 8.0. I don't know if GDB 8.0 suffers it too.
Maybe I'm missing something obvious since I searched the internet for quite a while but could not find a solution for the following problem:
I'm using Eclipse Kepler SP2 (Build id: 20140224-0627) with CDT and MinGW as compiler backend. Debugging C code with gdb worked great up until today (at least I noticed the problem today).
Now I get the following error message when i want to start a progam in the debugger:
Error in final launch sequence
Failed to execute MI command:
-file-exec-and-symbols C:/[...]/Debug/test.exe
Error message from debugger back end:
"C:\[...]\Debug\test.exe": not in executable format: File format not recognized
The program runs nicely and so I thought I might have screwed up some settings. But when I tried to debug an old program, everything worked until I recomplied the old program -> same problem. If I ask the C-wizard to create a new "Hello World" ANSI C application with MinGW, the same problem occurs.
The compile commands which were used are
gcc -O0 -g3 -Wall -c -fmessage-length=0 -o "src\\test.o" "..\\src\\test.c"
gcc -o test.exe "src\\test.o"
I did not update my MinGW in between, but updated Eclipse.
Do you have any pointers on where to look for the problem?
Edit: I just checked the binary type: My old projects are all [x86/le], the newly compiled ones are [amd64/le]. This should be a trace.... Will update posting according to progress.
Edit2: argh I installed strawberry perl a few days ago, and the installer has changed the environment variable MINGW_HOME in origin BUILD SYSTEM to c:\strawberry\c and this screwed up my builds. Resetting it to my c:\MinGW solved the issue.
I'll post this as answer, too. Heading and tags have been updated to point to this issue more directly.
I installed strawberry perl a few days ago, and the installer has changed the environment variable MINGW_HOME in origin BUILD SYSTEM to c:\strawberry\c and this screwed up my builds. Resetting it to my c:\MinGW solved the issue.
BTW: This happened, because strawberry added c:\strawberry\c to the PATH in front of my custom c:\MinGW and eclipse adds those to the BUILD SYSTEM variables.
It should be a parser problem, what is your binary parser under Project/Properties/Build/Settings ?
Check Project->Properties ->C/C++ Build ->environment and path for MINGW_HOME
make sure you have right gdb version (by checking under debug Configuration ->environment).
Here is an issue I've worked around by simply not using Eclipse for debugging, but it's getting out-of-hand.
I've used Eclipse Helios, Juno and Kepler over the last year and they all display exactly the same problem when I try to debug a local C/C++ application.
When I try to debug, it simply reports the error "Error while launching gdb --version".
gdb is in my path, but to be sure, I change the Debug settings to list the path explicitly. If I do that, I simply get "Error while launching /usr/bin/gdb --version", which is no better.
I'm using Scientific Linux version 6.4 (as required by my customers) and currently, I'm trying to use Eclipse Kepler. Running from the command line, gdb has no problem reporting it's version:
# gdb --version
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6)
[... licensing info]
Please, please let me know how to fix this as I have spent weeks working at only a fraction of the rate I would expect because I'm not utilizing an integrated development environment, but using separate tools.
I've seen other similar posts, but they are either
(a) about Windows / MingW - although I've tried their ideas anyway, just in case they work.
(b) don't have any answer provided.
As Scientific Linux is a RedHat derivative, I expect RHEL or CentOS information would be as relevant for me.
We have installed GDB on AIX 6.1 (gdb-6.0-1.aix5.1.ppc_AIX.rpm) and I notice that there is no "TUI" (terminal user interface) mode for "interactive source code debugging"?
Is that a known thing for GDB on AIX? Is there another way I can debug my application through the source code like using TUI mode on AIX? Perhaps using TTY somehow?
Thanks for the help
Lynton
Perhaps you need a more recent GDB. GDB is now at version 7.3.1 and gdb 7.2 has a --tui option.
Did you try to build GDB from its source code?
There is a same problem in my Mac OS X 10.6.6, then I try to build gdb 7.3.1 from source code, finally get the --tui option. While I use command "gdb --tui program" and typed "run" to debug, I get this message:
Unable to find Mach task port for process-id 36434: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
Then I use command "sudo gdb --tui program" to resolve it.
And there is a cgdb which based curses, and like TUI option.
See also question No TUI support for gdb on Mac?