I installed the Code::Blocks on a Windows 10 PC using the downloaded binary codeblocks-20.03-setup.exe. I adjusted the settings to point to my Msys2 MinGW compiler C:\msys64\mingw64 and debugger C:\msys64\usr\bin\gdb.exe. I then created a project with the default console app in c using Code::Blocks. It can compile and run using Code::Blocks.
When I debug it it fails. Code::Blocks gives an error:
Cannot open file: /c/GitLab/debugging-c-code/Exercise Files/Ch02/02_01/02_02_ide/main.c
At /c/GitLab/debugging-c-code/Exercise Files/Ch02/02_01/02_02_ide/main.c:6
The main.c file is open in Code::Blocks. I assume the /c/ vs c:\ part is the problem. I have no idea how to resolve the problem for Code::Blocks.
My Setup:
[..]which gcc
gcc is an external : C:\msys64\usr\bin\gcc.exe
[...]gcc --version
gcc (GCC) 9.1.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[...]which gdb
gdb is an external : C:\msys64\usr\bin\gdb.exe
[...]gdb --version
GNU gdb (GDB) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
I solved the problem ... after reading the comment from HolyBlackCat. Cygwin will mangle paths because it assumes it is inside the Cygwin environment.
Updated my MSYS installation and installed GDB as part of a complete toolchain:
pacman -S mingw-w64-x86_64-toolchain
Now GDB, GCC and Codeblocks are happy with each other and sharing debug information in a way that everybody understands. Now both GDB and GCC reside in C:\msys64\mingw64.
I originally only installed only GCC and then the other parts as I needed them.
Make sure you don't have any special characters (spaces, non ASCII characters) in the paths where CodeBlocks, MinGW-w64 or your source projects are located.
More info on how you can configure CodeBlocks with MinGW-w64 can be found here: https://winlibs.com/#usage-codeblocks
I am using libmicrohttpd 0.9.53 in my project and decided to update it to the latest version (0.9.71). I am cross-compiling for ARM and this is the output of arm-linux-gcc --version:
arm-linux-gcc (4.4.4_09.06.2010) 4.4.4
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
and the output of /lib/arm-linux-gnueabi/libc.so.6:
GNU C Library (Debian GLIBC 2.19-18+deb8u3) stable release version 2.19, by Roland McGrath et al.
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.8.4.
Compiled on a Linux 3.16.7 system on 2016-02-12.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.
The compilation is successful, however, I get these errors when linking with the shared library:
arm-linux-gcc -Llib/libmicrohttpd/lib -Wl,-rpath,./lib -o "proj" build/src/proj.o -lpthread -lm -lmicrohttpd
lib/libmicrohttpd/lib/libmicrohttpd.so: undefined reference to `pthread_setname_np#GLIBC_2.12'
lib/libmicrohttpd/lib/libmicrohttpd.so: undefined reference to `clock_gettime#GLIBC_2.17'
collect2: ld returned 1 exit status
make: *** [makefile:191: proj] Error 1
On the target machine, I ran /lib/arm-linux-gnueabi/libc.so.6 | grep clock_gettime:
782: 000e48e4 116 FUNC GLOBAL DEFAULT 12 __clock_gettime##GLIBC_PRIVATE
1625: 000e48e4 116 FUNC WEAK DEFAULT 12 clock_gettime##GLIBC_2.17
And readelf -Ws /lib/arm-linux-gnueabi/libc.so.6 | grep pthread_setname gives no result.
Apparently, the two symbols mentioned in the error have been added between the old and new releases and it seems like my current version of libc does not define them.
Am I completely off track here? Do I have to somehow update libc? Could you please suggest anything that could point me to the right direction?
It looks like your toolchain defaults -Wl,--as-needed. In this case, link order matters even for shared objects.
Try replacing -lpthread -lm -lmicrohttpd with this:
-lm -lmicrohttpd -lpthread
The clock_gettime#GLIBC_2.17 problem requires a rebuild with the version of glibc in your cross-build environment. It seems it was compiled on the target system (which has glibc 2.19, per your question), but it could have been built against any version that has clock_gettime in libc.so.6, starting with glibc 2.17. Your cross-compilation environment has a glibc version prior to that change (so glibc 2.16 or earlier), so it does not recognize the clock_gettime#GLIBC_2.17 symbol version.
I am trying to build a bare metal arm project. I tried the GNU toolchains arm-elf and arm-none-eabi. Executables generated by both toolchains, when converted to intel hex format, runs fine.
I am using the software Proteus for simulation. Proteus supports debugging executables in both elf and coff format.
In my case Proteus accepts the executable generated by arm-elf but its showing error when loading the executable generated by arm-none-eabi. The error message shown by Proteus is:
I just ran the file command in linux with the two executables as argument, one by one.
The results are shown below.
arm-none-eabi output
image: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped
arm-elf output
image: ELF 32-bit LSB executable, ARM, version 1, statically linked, not stripped
Is there any option to generate Proteus compatible elf file using arm-none-eabi toolchain?
Edit:
Details of my tollchains' versions.
C:\SysGCC\arm-elf\bin>arm-elf-gcc.exe --version
arm-elf-gcc.exe (GCC) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
C:\SysGCC\arm-elf\bin>arm-elf-as.exe --version
GNU assembler (GNU Binutils) 2.22
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `arm-elf'.
sreeyesh#ITP-PTLX118:~$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (15:4.9.3+svn227297-1) 4.9.3 20150529 (prerelease)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
sreeyesh#ITP-PTLX118:~$ arm-none-eabi-as --version
GNU assembler (2.25-10ubuntu1+5build1) 2.25
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `arm-none-eabi'.
Thanks in advance.
I finally found out the solution for the issue. I noticed that, in Proteus, there is an option to configure the toolchain and build the source code from Proteus itself.
I just did the following things in Proteus
Selected GNU ARM toolchain from the list of supported compilers
Configured the toolchain path to point to my arm-none-eabi toolchain.
Created a new project with an empty main function.
Built the project.
The build was successful and more interestingly I could debug the generated executable.
Proteus logs the build commands. When I analyzed the logs, I noticed that some extra options were being used by Proteus when invoking arm-none-eabi-gcc. I experimented with those extra options and finally found out that the option -gdwarf-2 plays the key role.
I updated my makefile with this option and it worked fine.
This option simply enables DWARF version 2 format, That's all that I understood from the web search. But why the arm-elf toolchain worked without this option is still a question in my mind. Maybe, this option is enabled in arm-elf by default.
Anyway I am satisfied with this finding as I can proceed with my work now.
Thanks to all those who spared their precious time to help me out. Hope this finding will help people experimenting with Proteus simulation using the GNU ARM toolchain.
I'm trying to debug libc on Ubuntu 14.04 but unable to do so using gdb as the library and the source are not matching correctly.
gdb is unable to place the break point correctly. As in, I'm able to step into a function and see the source code but the break point marker would be at some random place inside the function instead of being at the beginning.
When I proceed statement by statement using next on gdb, the marker would keep jumping up and down (Reason being the source file and debug library are not matching correctly.
My glibc version according to ldd is
ldd --version
ldd (Ubuntu EGLIBC 2.19-0ubuntu6.6) 2.19
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
I've downloaded libc sources using the command:
sudo apt-get source libc6
The above would create the following files:
eglibc-2.19
eglibc_2.19-0ubuntu6.6.debian.tar.xz
eglibc_2.19-0ubuntu6.6.dsc
eglibc_2.19.orig.tar.xz
In gdb I'm doing
dir <path-to-libc-source>/nptl (nptl because I'm stepping into pthread_create)
I've tried using both eglibc-2.19 source as well as eglibc_2.19.orig.tar.xz.
I've also tried setting LD_LIBRARY_PATH: export LD_LIBRARY_PATH=/usr/lib/debug
But the above also doesn't help.
Can somebody who has successfully been able to debug libc code share his/her techniques as to how to do it correctly?
Assuming the source code version and the library version are the same....
The root cause of the 'jumping' is due to the compiler optimization often changes the order of the executable code from the order in the source file.
This happens when the code is compiled with any of the optimization parameters.
This is my first question in StackOverflow since I joined some weeks ago and I wish someone could shed some light to this issue that drives me nuts! I've already searched thru the web, but I cannot find a successful solution to this problem.
I'm having some trouble with debugging with Netbeans 7.1 on Mac OSX 10.5.8 (Leopard) using GNU GDB. My problem is that I can't easily debug my own static or dynamic libraries from a test application because the debugger doesn't stop at breakpoints set in the source code of that libraries. However I've noticed that I can "step into" the library functions and, once I'm in them, breakpoints in those functions do fire!
My testbench consists on 2 simple projects: "mylib" (a C static library) and "mylib-test" (a C application). 'mylib' simply contains a header and a c file that define the function:
int sum(int a, int b) {
return a+b;
}
On the other hand, the mylib-test source simply uses that function:
int main(int argc, char** argv) {
printf("Result=%d\n", sum(111, 222));
return (EXIT_SUCCESS);
}
Both projects compile and execute successfully. For your convenience, below I put down the output of compiling/linking both projects:
Output of compiling mylib:
gcc -c -g -MMD -MP -MF build/Debug/GNU-MacOSX/m.o.d -o build/Debug/GNU-MacOSX/m.o m.c
mkdir -p dist/Debug/GNU-MacOSX
rm -f dist/Debug/GNU-MacOSX/libmylib.a
ar -rv dist/Debug/GNU-MacOSX/libmylib.a build/Debug/GNU-MacOSX/m.o
ar: creating archive dist/Debug/GNU-MacOSX/libmylib.a
a - build/Debug/GNU-MacOSX/m.o
ranlib dist/Debug/GNU-MacOSX/libmylib.a
Output of compiling mylib-test:
gcc -c -g -I../mylib -MMD -MP -MF build/Debug/GNU-MacOSX/main.o.d -o build/Debug/GNU-MacOSX/main.o main.c
mkdir -p dist/Debug/GNU-MacOSX
gcc -o dist/Debug/GNU-MacOSX/mylib-test build/Debug/GNU-MacOSX/main.o ../mylib/dist/Debug/GNU-MacOSX/libmylib.a
By examining the Debugger Console, I've noticed that breakpoints placed in the library's source code are marked as "PENDING" when I load the application on the debugger (see line starting by 12^done, field addr):
11-break-insert -f "/Users/claudi/dev/mylib-test/main.c:16"
12-break-insert -f "/Users/claudi/dev/mylib/m.c:5"
7^done,line="7",file="main.c",fullname="/Users/claudi/dev/mylib-test/main.c",time={wallclock="0.00065",user="0.00032",system="0.00029",start="1345544547.505531",end="1345544547.506184"}
(gdb)
13-break-insert -t main
&"cd /Users/claudi/dev/mylib-test\n"
8^done
(gdb)
9^done,time={wallclock="0.00002",user="0.00002",system="0.00000",start="1345544547.530991",end="1345544547.531013"}
(gdb)
&"set environment DYLD_LIBRARY_PATH=../mylib/dist/Debug/GNU-MacOSX\n"
10^done
(gdb)
11^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00001fb3",func="main",file="main.c",line="16",shlib="/Users/claudi/dev/mylib-test/dist/Debug/GNU-MacOSX/mylib-test",times="0"},time={wallclock="0.00058",user="0.00030",system="0.00029",start="1345544547.532421",end="1345544547.533003"}
(gdb)
12^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="/Users/claudi/dev/mylib/m.c:5",times="0"},time={wallclock="0.00040",user="0.00018",system="0.00022",start="1345544547.533140",end="1345544547.533542"}
(gdb)
13^done,bkpt={number="3",type="breakpoint",disp="del",enabled="y",addr="0x00001fb3",func="main",file="main.c",line="16",shlib="/Users/claudi/dev/mylib-test/dist/Debug/GNU-MacOSX/mylib-test",times="0"},time={wallclock="0.00017",user="0.00016",system="0.00001",start="1345544547.552190",end="1345544547.552362"}
It seems that GDB is not loading the symbols of the library, yet it is actually linked statically (I mean, there are no dynamic libraries to load)!!
However, if I step into function sum from the main() function, and then place the breakpoint, then it is successfully resolved:
21-break-insert -f "/Users/claudi/dev/mylib/m.c:5"
21^done,bkpt={number="4",type="breakpoint",disp="keep",enabled="y",addr="0x00001fea",func="sum",file="m.c",line="5",shlib="/Users/claudi/dev/mylib-test/dist/Debug/GNU-MacOSX/mylib-test",times="0"},time={wallclock="0.00099",user="0.00039",system="0.00060",start="1345544947.877096",end="1345544947.878088"}
I hope I've given enough information... Does anybody have an idea of what's going on? Thank you in advance!
Further info:
GCC version: 686-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5577)
GDB version: GNU gdb 6.3.50-20050815 (Apple version gdb-967)
Netbeans version: 7.1 (Build 201112071828)
////////////// EDIT //////////////////////////////////////////////////
So far I thought the problem was GDB, but today I've noticed it is not true: I've been able to debug the application directly using GDB from the command line, i.e., I could set breakpoints to my sum function and the debugger successfully stopped at them without the need to step into the function. So, I'm sure I'm having some issue with how NetBeans starts/initializes GDB. I've also noticed that NetBeans is trying to get features from GDB without success. From the debugger console:
~"GNU gdb 6.3.50-20050815 (Apple version gdb-967) (Tue Jul 14 02:11:58 UTC 2009)\n"
~"Copyright 2004 Free Software Foundation, Inc.\n"
~"GDB is free software, covered by the GNU General Public License, and you are\nwelcome
to change it and/or distribute copies of it under certain conditions.\nType \"show
copying\" to see the conditions.\nThere is absolutely no warranty for GDB. Type \"show
warranty\" for details.\n"
~"This GDB was configured as \"i386-apple-darwin\"."
~"\n"
(gdb)
2-list-features
3-gdb-set print repeat 0
4-gdb-set backtrace limit 1024
5-gdb-set print elements 0
6-file-exec-and-symbols "/Users/claudi/dev/mylib-test/dist/Debug/GNU-MacOSX/mylib-test"
2^error,msg="Undefined MI command: list-features"
I have no answer for this issue but I have some clues that could help finding solution.
I belive it's not NetBeans' fault. It's something with gdb. Probably it has to be compiled with some special configuration flag(s).
I was using gdb 7.4 (downloaded while ago with MinGW) with NetBeans 7.0-7.2 and Eclipse Juno on Windows 7 and everything was working as expected - gdb was stopping when entering breakpoints in my libraries (static or dynamic).
Lately I wanted to migrate to gdb compiled with Python support to get pretty-printing of complex STL structure in Eclipse. So I've downloaded latest gdb 7.5 sources and I've compiled it with "--with-python" flag:
./configure --with-python
make && make install
Pretty pretting works. Not even on Eclipse but with NetBeans as well (you only need to point to .gdbinit file in Project's Debug settings). The problem is my own compiled version of gdb has no ability to stop on breakpoints in my libraries (on NetBeans 7.2 and Eclipse Juno).
My conclusion is that gdb should be compiled with some flag(s) to get this ability. Or maybe it would be just sufficient to run it with some flag(s). I would also be grateful for help with this issue.
I'm attaching some possible useful informations:
Screenshots with correct stack trace on gdb 7.4
Screenshots with incorrect stack trace on gdb 7.5
Correct gdb:
C:\MinGW\bin>gdb --version
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
C:\MinGW\bin>gdbserver --version
GNU gdbserver (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
gdbserver is free software, covered by the GNU General Public License.
This gdbserver was configured as "i686-pc-mingw32"
Incorrect gdb:
C:\MinGW\bin>gdb --version
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
C:\MinGW\bin>gdbserver --version
GNU gdbserver (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
gdbserver is free software, covered by the GNU General Public License.
This gdbserver was configured as "i686-pc-mingw32"
I've checked at my work if absence of libexpat is causing gdb problem you described. And it seem that this is the case :) Try to compile and install expat first and then compile gdb from soruces.
Be sure to have:
checking for libexpat... yes
checking how to link with libexpat... <some_path>/libexpat.a
in your logs (somewhere after "make" command. not after "./configure").
To compile gdb I used gcc 4.6.2 from MinGW under Windows 7 and gdb-7.5 sources. I also added two additional configure flags but for sure they aren't necessery:
./configure --with-python --without-auto-load-safe-path