I have previously installed GDB to debug C in eclipse, which is working perfectly. I want to do the same now with my cortex m-3, however I can't make a binary object using GDB because it is giving me an error.
I want to make a binary file the following way:
as -mcpu=cortex-m3 -mthumb example1.s -o example1.o
It does not recognize my cortex-m3 and it is giving me the following error:
as: unrecognized option `-mcpu=cortex-m3'
When doing a version check with my GDB it says the following:
This GDB was configured as "x86_64-w64-mingw32".
Is there a way to switch this to arm-none-eabi?
I hope someone can help me.
This isn't really a question about gdb. gdb is the debugger. as is the assembler.
You want to build or get a cross-assembler.
Well, actually it WAS a question about the GDB, because I did not really understand how it worked. I have fixed it now.
I have moved my assembly file to the folder containing my Atollic GDB debugger for ARM processors and did the same command. He interpreted the right MCPU, and the binary file has been made now.
Related
I have created and successfully compiled a C++ application for Linux using eclipse. When I debug it from the command line everything works perfect, I can debug just fine.
But I require debugging in eclipse because is more convenient and easy. I configure the debug session and when trying to launch it I get the error:
Error in final launch sequence
Failed to execute MI command:
-exec-run
Error message from debugger back end:
Warning:\nCannot insert breakpoint 1.\nCannot access memory at address 0x1fff82e8\nCannot insert breakpoint 2.\nCannot access memory at address 0x80001ea4\n
Warning:\nCannot insert breakpoint 1.\nCannot access memory at address 0x1fff82e8\nCannot insert breakpoint 2.\nCannot access memory at address 0x80001ea4\n
But I have no idea why I am getting that error, especially because gdb is working fine when I execute it from cmd.
These are my c++ compiler flags in eclipse:
-std=c++98 -O0 -g3 -Wall -c -fmessage-length=0
When creating the project I chose the "Hello world C++ Project" and the "Linux GCC" as the toolchain.
I'm working with the following versions of GDB and Eclipse:
Eclipse Neon.1a Release (4.6.1)
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
The only way I can reproduce this problem is to have address breakpoints enabled. As far as I am concerned this is a bug in CDT, but in the meantime as a workaround remove or disable any address breakpoints from the Breakpoints view.
I have submitted Bug 509894 to track the issue in CDT.
Whenever I try to debug TensorFlow's C++ code with Eclipse + GDB, I get GDB crashing, or actually exiting with: error code = -1.
As long as I don't set a breakpoint in TensorFlow's C++ code, the program runs just fine. But when I do, and when the debugger gets to the breakpoint, it crashes after a few seconds with error code -1. There is nothing meaningful in the GDB traces which can explain this behavior.
The GDB version I am using is 7.7.1, running with Eclipse Neon under Ubuntu 14.04.
TensorFlow is compiled in debug mode. I don't think that Eclipse is missing the debug symbols for it, as it is not complaining that those are missing (and also, occasionally, the debugger is able to step through a few steps in the code before it crashes).
An easy way to reproduce is to try and debug the label_image example:
https://www.tensorflow.org/versions/r0.11/tutorials/image_recognition/index.html
Compile it and then create a 'C/C++ Application' debug configuration in Eclipse, directing it to the compiled binary of the label_image app.
I've encountered the same problem with GDB on macOS. But, I finally succeeded to debug tf with lldb. And I also found that using VisualStudio Code + lldb makes it easy for debugging.
Here is my way of debugging. Maybe you can give it a try.
I'm working on a relatively old Centos system where I am restricted in the packages I can install. I needed a newer version of gdb, so I built that successfully from source in my home dir. This gdb steps through my code fine, but I am looking for trouble that is manifesting in the C++ allocator (mt_allocator.cc) and this new version of gdb can't step through that code. I can break successfully on a function there:
break '__gnu_cxx::__pool<true>::_M_initialize()'
but when that breakpoint hits and I try to step through the code, gdb tells me:
Single stepping until exit from function _ZN9__gnu_cxx6__poolILb1EE13_M_initializeEv,
which has no line number information.
I tried using the dir command within gdb to add the path to where mt_allocator.cc is, but that had no effect.
What do I need to tell gdb so it can find those files?
Ah, found it. The Centos package manager put the debug files for the STL code at /usr/lib/debug. So:
set debug-file-directory /usr/lib/debug
within gdb gets it done.
This is probably a very basic question. However, I couldn't find any answer by searching the web.
I have a code I need to debug written in C++. For this code, I require to use GCC 4.1.2 in compatibility reasons and I am using GDB 6.6-45. I compiled the code with the -g -Wall -O0 flags to make sure the code can be debugged with GDB.
My problem is that wherever I set the breakpoint, no breakpoints get hit. Also, at the end of the run, I get this message "You can't do that without a process to debug".
By the sound of the message, I think I am missing a very trivial thing. However, I cannot figure out.
Any help would be appreciated.
EDIT:
The platform I am working on is Fedora 8 on VirtualBox. The reason why I am working on VirtualBox is because I wasn't good enough to install older version of GCC (4.1.2) properly without breaking Fedora 20, which is the latest.
As per GDB output, (it's very basic):
[localhost]$ gdb programName
GNU gdb Red Hat Linux (6.6-45.fc8rh)
... typical messages
This GDB was configured as "i386-redhat-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run programName (program arguments here)
...
Program outputs and messages
...
Program exited normally.
You can't do that without a process to debug.
(gdb)
What's shown above is all I have. To set my breakpoints, I did something similar to:
break main
break System::function_name
break System::line_number
and when I run info breakpoints, the breakpoints does show correct cpp file and the line number or the function name, with enabled flag to yes.
If possible try to avoid -O flag and just use -g -Wall only. I have seen some problems with -O flag in older versions. But I'm not sure whether they persist in novel gcc as well. Just give it a try.
A shared object was built on RedHat Linux and while all the code was compiled with debug, the debugger (gdb) refused to load the symbols and issued an error as in:
...
GNU gdb Fedora (6.8-37.el5)
...
This GDB was configured as "x86_64-redhat-linux-gnu"...
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module libgrokf.so]
With this error, I could not get break points to trigger in any function nor see proper stack trace. I recompiled the entire project but nothing helped. I do know that some time in the past there was no problem in debugging that module.
What is causing this problem?
The problem is that your version of gdb doesn't support the DWARF version used in one of your binaries.
The solution: Update gdb or compile your files using another debug format (DWARF2 works on gdb 6).
I have recently had this problem with freeBSD and nasm, nasm compiling binaries with DWARF3 and the gdb that ships with freeBSD 9.1 doesn't accept it.
I hope this answer helps anyone having a similar problem :P
Debug options for GCC
As it happens, the module that could not debug was mostly built from sources except for one little 'external' object file someextcode.o that was provided by a 3rd party.
In investigating the problem it was found that the someextcode.c was compiled with the -g3 flag which, apparently, places DWARF version of 4 in the compilation unit header. Changing that to -g resolved the problem.
Unfortunately, it appears a problem with a single module can break the debug-ability of an entire shared object (.so) without giving a clear indication of root of the problem.
My issue got resolved by choosing the right gdb version for debugging. Earlier I was using the gdb 7.0... and when I started using the gdb version 7.10, i was able to debug my application.