I have this kind of message when I start gdb :
$ gdb a.out
GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu Nov 3 21:59:02 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .
warning: Could not find object file "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libstdc++-v3/src/../libsupc++/.libs/libsupc++convenience.a(array_type_info.o)" - no debug information available for "../../../../gcc-4.7.0/libstdc++-v3/libsupc++/array_type_info.cc".
warning: Could not find object file "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libstdc++-v3/src/../libsupc++/.libs/libsupc++convenience.a(bad_alloc.o)" - no debug information available for "../../../../gcc-4.7.0/libstdc++-v3/libsupc++/bad_alloc.cc".
It seems that I need to fetch again the libstdc++ but how with macports?
This is one of several problems caused by the special Unix environment installed by Apple as part of Xcode. If you need a newer version of gcc than the one installed by Xcode, make sure you also install a newer version of gdb, or you will get the problems described above. You also need to make sure that your environment actually calls the macport versions of both and not the default Xcode versions.
Just installing gcc from macports will NOT make the command 'gcc' invoke the version of gcc installed by macports. Similarly, 'gdb' will not invoke the version of gdb installed by macports. The versions installed by macports have the paths '/opt/local/bin/gcc-mp-4.6' and '/opt/local/ggdb' or something similar dependent on the version number of gcc. Note that it is 'ggdb' and not 'gdb'.
One solution is to always explicitly invoke the right version by giving the entire path. Another is to replace the default gcc and gdb locations with links to the macports versions (this may cause problems with Xcode possibly). The default locations are '/usr/local/bin/gcc' and '/usr/bin/gdb'. The default bash shell will look in those locations regardless of your path settings.
http://gcc.gnu.org/gcc-4.5/changes.html says
GCC now generates unwind info also for epilogues. DWARF debuginfo generated by GCC now uses more features of DWARF3 than before, and also some DWARF4 features. GDB older than 7.0 is not able to handle either of these, so to debug GCC 4.5 generated binaries or libraries GDB 7.0 or later is needed. You can disable use of DWARF4 features with the -gdwarf-3 -gstrict-dwarf options, or use -gdwarf-2 -gstrict-dwarf to restrict GCC to just DWARF2, but epilogue unwind info is emitted unconditionally whenever unwind info is emitted.
So you should see if there is a newer GDB in macports.
Related
I am trying to cross-compile Linux for QEMU (RV64G ISA, lp64d ABI, Virt machine) using Buildroot. But apparently, GDB has been removed from buildroot version I'm using (2019.08), and is listed under the legacy list.
My objective is to be able to run RISC-V Linux application (in user-mode and softmmu) and with GDB debugging. I was able to build and run RISC-V apps using QEMU in both modes. But I didn't find a way to generate GDB like the other host utilities. Any ideas on how to do that?
A possible procedure for building a riscv64-linux-gnu-gdb from scratch would be :
PREFIX=$(pwd)/gdb-8.3.1-riscv64-linux-gnu
wget ftp://ftp.gnu.org/gnu/gdb/gdb-8.3.1.tar.xz
tar Jxf gdb-8.3.1.tar.xz
mkdir gdb
cd gdb
../gdb-8.3.1/configure --program-prefix=riscv64-linux-gnu- -with-tui --target=riscv64-linux-gnu --prefix=${PREFIX}
make all install
cd -
Build artifacts will located in $(pwd)/gdb-8.3.1-riscv64-linux-gnu:
ls -gG gdb-8.3.1-riscv64-linux-gnu/bin/riscv64-linux-gnu-gdb
-rwxr-xr-x 1 80395824 Sep 26 14:16 gdb-8.3.1-riscv64-linux-gnu/bin/riscv64-linux-gnu-gdb
gdb-8.3.1-riscv64-linux-gnu/bin/riscv64-linux-gnu-gdb --version
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 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.
If you don't want to build GDB with the TUI interface, remove --with-tui from the ./configure command.
I hope this helps.
gdb has certainly not been removed from Buildroot! However, back when the RISC-V support was added in Buildroot, the gdb support was not included, and therefore BR2_PACKAGE_HOST_GDB_ARCH_SUPPORTS depends on !BR2_riscv, which hides gdb when the RISC-V architecture is selected.
So one would need to see if there is an upstream version of gdb that supports RISC-V, and if there is, remove the !BR2_riscv dependency, and add the appropriate dependencies to prevent the user from selecting older gdb versions that don't have RISC-V support.
I have run in an issue with compiling gdb from source. I am downloading version 8.2.1 but when I try to compile it, I get the following error:
configure: error: *** A compiler with support for C++11 language features is required.
make[1]: *** [configure-gdb] Error 1
My operating system is Red Hat 7.6 (Maipo) but i have a compiled from source gcc(that i set as the default one with an alias in bashrc)
gcc --version
gcc (GCC) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
which gcc
alias gcc='/usr/local/gcc8.2/bin/gcc'
/usr/local/gcc8.2/bin/gcc
which g++
alias g++='/usr/local/gcc8.2/bin/g++'
/usr/local/gcc8.2/bin/g++
What i have tried/read so far
Read the gdb manual regarding the configure and instalation part, also various stackoverflow links but nobody seems to have this problem
Read the README file in the gdb folder/subfolders
Tried setting the following env options CXX_FOR_TARGET=/usr/local/gcc8.2/bin/g++ GCC_FOR_TARGET=/usr/local/gcc8.2/bin/gcc (not sure if i should replace target with my actual target architecture)
Looked in the gdb-8.2.1 folder at the file config.log and found these: ac_cv_env_GCC_FOR_TARGET_value=/usr/local/gcc8.2/bin/gcc
ac_cv_prog_CXX_FOR_TARGET=/usr/local/gcc8.2/bin/g++
ac_cv_prog_GCC_FOR_TARGET=/usr/local/gcc8.2/bin/gcc
However in the C compiler section of the same config log I have found the following:
configure:4284: checking for C compiler version
configure:4293: gcc --version >&5
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
Copyright (C) 2015 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.
I am not sure ifi can use the devtoolset-8 gdb from RedHat because i have compiled gcc with GLIBCXX_USE_CXX11_ABI=1 and on RedHat due to a bug this is disabled by default and i am not sure if gdb will be able to manage the different binary interface.
Short version: What am I doing wrong that is making the GDB configure script not find the correct compiler and how can i fix/workaround this?
Thank you very much for your help!
A C++11-capable compiler for Red Hat Enterprise Linux 7 is provided as part of Red Hat Developer Toolset. It happens to include not just GCC 8, but GDB 8.2 as well, so you may not even have to compile it yourself. The DTS C++ compiler has been built in a special way so that it interoperates with the system C++ runtime. Unless you have replicated those modifications in your GCC build, it will not be compatible with the rest of the system (and you will have to replace the system libstdc++ library).
The system compiler in Red Hat Enterprise Linux 7 is based on GCC 4.8. In that version, C++11 support was still experimental and not enabled by default. You can try to configure GDB with
./configure CXX="g++ -std=gnu+11"
but this is not recommended (only the C++98 mode is supported).
The configure script does not use shell aliases because those are not inherited by shell scripts invoked from a shell. You will have to specify the full path to the C++ compiler explicitly (in the CXX= argument to configure), or adjust the PATH environment variable manually, or use scl enable to do so in a more polished fashion (for software collections such as Developer Toolset).
According to the address-sanitizer home page it comes only with the gcc 4.8 or above. Isn't there anyway of using it with gcc 4.7?
No, there is no reliable way (to get ASAN before GCC 4.8). ASAN requires compiler support and is very intimately connected to your particular compiler (and version, and host and target systems, and specific configuration, etc...)
In other words, try to compile a recent GCC (that is, GCC 5.2 in july 2015; use that since ASAN did progress since 4.8 and you'll get more -fsanitize= options in recent versions of GCC) from its downloaded source code. See hints here & there. You should try some recent Linux distribution.
(on Linux or other POSIX systems, you don't need root privileges to configure, compile, and install gcc-mine-5 in $HOME/soft/; you need appropriate ../gcc-5.2/configure options, notably --prefix=$HOME/soft --program-suffix=-mine-5, then add $HOME/soft/bin/ in your PATH then run with CC=gcc-mine-5 e.g. for make)
I'm trying to build a binary with GCC 4.9.0 that is backwards-compatible against libstdc++. According to GCC's ABI Policy and Guidelines and Options Controlling C++ Dialect, the command line option -fabi-version should do the trick; however, no matter which version I set, I still get imports of symbols from a version newer then desired, like this:
$ objdump -T binary | grep GLIBCXX_3.4.20
00000000 DF *UND* 00000000 GLIBCXX_3.4.20 _ZSt24__throw_out_of_range_fmtPKcz
I've tried -fabi-version=1 to -fabi-version=5 (ABI version 5 corresponds to GCC 4.6, which is guaranteed to be present on the target system), but those imports keep winding up in the resulting files.
How do I fix this? Going back to an old GCC version is not an option to me for other reasons.
the command line option -fabi-version should do the trick
No, that's completely unrelated to what you want. That option affects the code generated by the compiler, it does not mean you can link to an older version of libstdc++ (which is what you would need in order to stop depending on symbols in the newer libstdc++).
You cannot link to an older libstdc++ with a new GCC. The version of libstdc++ is tightly coupled to the version of GCC, so if you want to linker to an older libstdc++ then you need to compile with an older GCC.
You cannot tell libstdc++ to not use the new symbols, the reason it depends on them is because it needs them. Use an older libstdc++.
Going back to an old GCC version is not an option to me for other reasons.
Then you're screwed.
You either need to use an older GCC, or not link dynamically to libstdc++.so.
On Red Hat Enterprise Linux or CentOS you would have the option of using a newer GCC from the Developer Toolset which avoids linking to the new libstdc++.so but that is only compatible with the system GCC, which is GCC 4.4 for RHEL6 or GCC 4.7 for RHEL7. You can't use it to be compatible with GCC 4.6.
I've been trying to find an answer to this on stackoverflow for about an hour now, seems that a lot of similar problems are around but none really fitting to mine.
Information about what tools I'm using can be found further down!
I am writing my own compiler for a subset of the java language and thus creating assembler code. Now I'm at a point where I need to debug said assembler code to locate a bug. The problem is when I compile my assembler code to a binary with gcc -m32 -g myAssembler.s I get the following warning:
warning: no debug symbols in executable (-arch i386)
(This warning also occurs using -ggdb, -ggdb2, -ggdb3, -g2, -g3instead of -g
Since there are no debug symbols I can't use gdb to debug my code. I don't know much about linking and how it's done or who does it (especially on a Mac), so precise/noob-friendly answers would be very welcome.
Tools I'm using:
The assembly created from my compiler is x86, 32-bit GAS Syntax.
I am using OS X Mavericks with GNU gdb (GDB) 7.6 downloaded via MacPorts (They changed its name to ggdb. The ggdb --version command shows also a line saying :
This GDB was configured as "x86_64-apple-darwin13.0.0".
(Not quite sure if that's important.)
Running gcc --version returns:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
This is probably connected with Apple dropping support for GDB in Xcode 5 and you are using the version of gcc that comes with Xcode 5. You probably need to change compiler or debugger (to lldb)… you might look at llvm-gcc (which Xcode 5 also drops support for). Try www.llvm.org for a download. But that might be more trouble than using lldb (if your problem is indeed connected to Xcode 5's changes). Good luck! – CRD
I just downloaded gcc-4.2 from homebrew and that seems to work for lldb (which is still supported by Xcode 5 it seems). – Octoshape