I am trying to figure out a very strange issue. I have CentOS 6.5 system with gdb:
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6)
and gcc:
gcc (GCC) 4.8.2 20131212 (Red Hat 4.8.2-8)
I have this file:
#include<stdio.h>
int main()
{
printf("OK!");
return 0;
}
which I compile with:
gcc -o a a.c -g -O0
The file seems to be fine:
$ file a
a: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
But when I try to debug it, this happens:
$ gdb a
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6)
Copyright (C) 2010 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 "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from a...done.
(gdb) b main
Breakpoint 1 at 0x4004e4
(gdb) r
Starting program: a
Breakpoint 1, 0x00000000004004e4 in main ()
(gdb) l
1 /* Run time dynamic linker.
2 Copyright (C) 1995-2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
3 This file is part of the GNU C Library.
4
5 The GNU C Library is free software; you can redistribute it and/or
6 modify it under the terms of the GNU Lesser General Public
7 License as published by the Free Software Foundation; either
8 version 2.1 of the License, or (at your option) any later version.
9
10 The GNU C Library is distributed in the hope that it will be useful,
(gdb) l main
No line number known for main.
I.e., gdb refuses to see any debug information. Anybody has an idea what could be a problem here?
Your GDB is pretty old. Your GCC is fairly new.
I suspect that your GCC is emitting DWARF4 debug info (default as of gcc-4.8 according to release notes), which your GDB does not recognize.
Do you get better result with -gdwarf-2 instead of -g?
If so, upgrade your GDB or use -gdwarf-2 with this compiler.
Related
I have compiled the very simple program
$ cat main.cpp
#include <iostream>
int main() {
uint64_t val=1;
// val = htobe64(val);
std::cout << val << std::endl;
}
$ g++ -g main.cpp -o a.out
When I debug it using cgdb I get the following:
$ cgdb a.out
But when I uncomment the line // val = htobe64(val) something strange happens:
$ cat main.cpp
#include <iostream>
int main() {
uint64_t val=1;
val = htobe64(val);
std::cout << val << std::endl;
}
$ g++ -g main.cpp -o a.out
$ cgdb a.out
Uncommenting this single line causes cgdb to start showing the splash screen and when I type start as in the screenshot it only gives me assembler code (before cgdb started directly showing the source code and not its splash screen). Furthermore somehow the file path /home/user/byteswap.h appears in the screenshot, but this file does not exist (In this example user is was my username and /home/user my working directory).
Can someone tell me what is happening here and what I can do to be able to debug a program that is calling htobe64, i.e. how to achieve that cgdb will show me the source code as in the first example at the top?
Here are the tool versions:
$ cgdb --version
CGDB 0.7.1
Copyright 2002-2019 Bob Rossi and Mike Mueller.
CGDB 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.
There is absolutely no warranty for CGDB.
$ gdb --version
GNU gdb (Debian 8.2.1-2+b3) 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.
$ g++ --version
g++ (Debian 11.2.0-10) 11.2.0
Copyright (C) 2021 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.
When posting this questions I became aware of the fact that my g++ version is very new compared to my gdb version (I recently updated it to have better C++20 support).
I turns out that updating the gdb version solved the problem: With gdb version GNU gdb (Debian 10.1-2) 10.1.90.20210103-git the problem is no longer present. I admit that I should have verified this before posting but I do not delete the question because it may help others having similar strange obervations.
I'm trying to debug a segfault in a homework program and I've discovered that my GDB can no longer even print std::strings. How can I fix it?
I'm on Ubuntu 18.04 LTS.
CLang++ version:
$ clang++ --version
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
GDB version:
$ gdb --version
GNU gdb (Ubuntu 8.1-0ubuntu3.1) 8.1.0.20180409-git
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. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
I've writen a small test program called gdbbroke.cpp:
#include <string>
int main()
{
std::string test = "sanity check";
return 0;
}
gdbbroke$ clang++ -o gdbbroke gdbbroke.cpp -std=c++11 -Wall -Wextra -Wpedantic -Wconversion -Wnon-virtual-d
tor -ggdb
gdbbroke$ gdb ./gdbbroke
[...]
Reading symbols from ./gdbbroke...done.
(gdb) break main()
Breakpoint 1 at 0x4007a3: file gdbbroke.cpp, line 5.
(gdb) run
Starting program: gdbbroke/gdbbroke
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main () at gdbbroke.cpp:5
5 std::string test = "sanity check";
(gdb) print test
$1 = Python Exception <class 'gdb.error'> There is no member named _M_dataplus.:
(gdb)
I expected print test to output:
(gdb) print test
$1 = "sanity check"
However it just throws the Python error above.
With Clang, to print the string you need debug symbols of libstdc++ to be installed.
See this Clang bug resolved as INVALID https://bugs.llvm.org/show_bug.cgi?id=24202.
The string should be printed if you install libstdc++ debug symbols. On the other hand you can simply use GCC instead of Clang. In that case you don't need to install libstdc++ debug symbols because GCC already emits them. Clang does not emit them because it does debug information optimization while GCC does not do it. See also related question Cannot view std::string when compiled with clang.
Here is a simple program:
#include <iostream>
#include <vector>
namespace Example
{
template <int dim>
class Problem
{
public:
void run() {
std::cout<<"here.."<<std::endl;
}
};
}
int main(int argc, char *argv[])
{
Example::Problem<2> problem;
problem.run();
return 0;
}
compiled with Macport's gcc 4.7.3:
g++-mp-4.7 -g -O0 prog.cc -o prog
If I try to debug in gdb 7.7 (self-compiled, not Macport's one!):
$gdb
file prog
b main
r
s
I can't step-in the function:
34 problem.run();
(gdb) s
here..
36 return 0;
(gdb)
Am i doing something wrong? Or does it look like a bug of gdb when used on os-x mavericks?
UPDATE:
I don't see any warning/errors when using gdb:
$ gdb ./prog
GNU gdb (GDB) 7.7
Copyright (C) 2014 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 "x86_64-apple-darwin13.1.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./prog...Reading symbols from /Users/bla-bla-bla/prog.dSYM/Contents/Resources/DWARF/prog...done.
done.
(gdb)
also '-gdwarf-2 -gstrict-dwarf' do not change the behaviour....
UDAPTE2:
I see the same missing call-stack behaviour as here. Although I was not able to check if compiling with -m32 helps in my case, since I have everything for 64bit and thus get undefined symbols problems.
Another stepping problem while debugging is reported here and here on SO.
You need to add -gdwarf-2 option along with -g to debug using gdb for newer version of gcc.
g++-mp-4.7 -g -gdwarf-2 -O0 prog.cc -o prog
When I used gdb7.6 to analyse the corefile,gdb print the following error:
"./core: no core file handler recognizes format"
My Environment:
HP-UX hp12161 B.11.31 U ia64 0546304299.
Compiler:gcc4.7.2.
gdb7.6 Configure=./configure --enable-64-bit-bfd.
I noticed that in ia64-hpux platform gdb not call set_gdbarch_regset_from_core_section、 deprecated_add_core_fns Interface.
How should I do to solve this problem?
You should use the HPE Wildebeest Debugger. This is HPE's fork of GNU gdb that works on hp-ux. The GNU gdb does not work on hp-ux, neither on executables built with hp-ux aCC nor with those built with gcc.
For example, with whatever version of gdb is available on this system:
[ hp-ux_ia64 ~ ] $ gcc --version
gcc (GCC) 4.7.1
Copyright (C) 2012 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 make a program dump core:
[ hp-ux_ia64 ~ ] $ cat > 1.c
main () { ((int*)0)[0]=1; }
[ hp-ux_ia64 ~ ] $ gcc 1.c
[ hp-ux_ia64 ~ ] $ ./a.out
Segmentation fault (core dumped)
Running GNU gdb on it, I can reproduce the problem you face.
[ hp-ux_ia64 ~ ] $ /usr/local/bin/gdb -c core
GNU gdb (GDB) 7.6.2
Copyright (C) 2013 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 "ia64-hp-hpux11.23".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
"/user/ranga/core": no core file handler recognizes format
(gdb) quit
HPE gdb gives me a proper stack trace.
[ hp-ux_ia64 ~ ] $ /opt/langtools/bin/gdb -c core
HP gdb 6.7 for HP Itanium (32 or 64 bit) and target HP-UX 11iv2 and 11iv3.
Copyright 1986 - 2011 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 6.7 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
Reading symbols from a.out...(no debugging symbols found)...done.
Core was generated by `a.out'.
Program terminated with signal 11, Segmentation fault.
SEGV_ACCERR - Invalid Permissions for object
#0 0x4000870:0 in main+0x10 ()
(gdb) bt
#0 0x4000870:0 in main+0x10 ()
(gdb)
Below details are from a session in a Sun machine running Solaris 10.
$ file devli
devli: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped
$ file a
a: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped
$ gdb
GNU gdb 6.4
Copyright 2005 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 "sparc-sun-solaris2.10".
(gdb) file a
Reading symbols from /tmp/tnmy/a...(no debugging symbols found)...done.
(gdb) file devli
"/tmp/tnmy/devli": not in executable format: File format not recognized
(gdb) q
$ ls -l a devlisrvr
-rwxr-xr-x 1 test2 dba 1480 Dec 23 18:23 a
-rwxr-xr-x 1 test2 dba 633088 Dec 23 18:26 devli
$ uname -a ;
SunOS myhost 5.10 Generic_127111-11 sun4v sparc SUNW,SPARC-Enterprise-T5220
$ cat a.c
int main() {return 0;}
$ /opt/SUNONE8/SUNWspro/bin/CC -V
CC: Sun C++ 5.5 2003/03/12
$ file `which gdb`
/usr/local/bin/gdb: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped
$
Any details on why would not gdb recognize the file format for devli? I searched over the Internet but could not find anything related to this particular issue. Any pointers would be helpful.
a.c goes into a, built using gcc; devli using Sun ONE Studio 8.
Note that GDB 6.4 is 4 years old. You might get better luck with (current) GDB 7.0.
It is also possible that the devli executable is corrupt (file just looks at the first few bytes of the executable, but GDB requires much more of the file contents to be self-consistent). Does readelf --all > /dev/null report any warnings?