gdb wrong filename in shared library - c++

Trying to learn fmbt ,in the c++ test it is using a shared library, the source file of the shared library is preprocessed from another file as in the following make output shows:
g++ -O0 -g -Wall -pedantic -I../../src -I/usr/include/fmbt -fPIC -c -o mycounter.o mycounter.cc
fmbt-aalc -o mycountertest.cc mycountertest.cc.aal
g++ -O0 -g -Wall -pedantic -I../../src -I/usr/include/fmbt -fPIC -c -o mycountertest.o mycountertest.cc
g++ -shared -o mycountertest.so mycounter.o mycountertest.o
When I am trying to debug the shared the library, it always go to the mycountertest.cc.aal file:
ubuntu#i-hics5mzq:~/fMBT/examples/c++-unittest$ gdb fmbt
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.3) 7.7.1
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-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"...
Reading symbols from fmbt...done.
(gdb) break awrapper.cc:149
Breakpoint 1 at 0x585e06: file awrapper.cc, line 149.
(gdb) run test.conf
Starting program: /usr/local/bin/fmbt test.conf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
<fmbt_log>
<version>
0.38-1
</version>
<conf_load>
<conf_file name="test.conf"/>
<end_time time="1501727367.947618"/>
</conf_load>
<conf_execute>
<action_name name="iCreate"/>
<action_name name="iDestroy"/>
<action_name name="iIncrement"/>
<action_name name="iReset"/>
<action_name name="iCount"/>
<test_engine>
<tags enabled=""/>
<status steps="0" coverage="0.000000" scov="0.000000e+00"/>
<current_time time="1501727366.958535"/>
<suggested_action type="input" name="iCreate" time="1501727366.958600"/>
Breakpoint 1, Awrapper::execute (this=0x93b6d0, action=std::vector of length 1, capacity 1 = {...}) at awrapper.cc:149
149 int tmp=ada->adapter_execute(1,"");
(gdb) s
_gen_mycountertest::adapter_execute (this=0x94ce50, action=1, param=0x65f8b0 "") at mycountertest.cc.aal:27
27 adapter() {
why gdb is not using the generated mycountertest.cc file.
here is the mycountertest.cc content, does the special class name has something to do with it ? :
#line 3 "mycountertest.cc.aal"
#include "mycounter.h"
#include "aal.hh"
class _gen_mycountertest:public aal {
private:
#line 6 "mycountertest.cc.aal"
//variables
MyCounter* mycounter;
int value;
//action1: "iCreate"
#line 17 "mycountertest.cc.aal"
bool action1_guard(const std::string& name) {
{
return mycounter == NULL;
}
return true;//default
}

why gdb is not using the generated mycountertest.cc file
Because it was told not to. In particular, this line:
#line 17 "mycountertest.cc.aal"
bool action1_guard(const std::string& name) {
tells GCC to tell GDB that whatever code follows was generated from line 17 of mycountertest.cc.aal, so that's what GDB will show.
Usually that's exactly what one wants for generated code.
You can safely strip the #line directives from mycountertest.cc before compiling it, and then GDB will show you the generated source:
fmbt-aalc mycountertest.cc.aal | sed -e '/^#line/d' > mycountertest.cc

Related

"Python Exception <class 'gdb.error'> There is no member named _M_dataplus." when trying to print string

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.

objdump -W sees line numbers, objdump -drl and gdb don't? [duplicate]

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.

gdb 7.7 does not step-in on OS-X Mavericks with gcc4.7.3 (Macports)

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

Using libc++ causes GDB to segfault on OS X

I'm trying to use C++11 (with Clang and libc++ on OS X) for a program, but whenever I debug with gdb and try to inspect standard containers, gdb segfaults. Here's a minimal example:
file.cpp:
#include <iostream>
#include <string>
int main(int argc, char* argv[])
{
std::string str = "Hello world";
std::cout << str << std::endl; // Breakpoint here
}
If I compile for C++11 using the following:
$ c++ --version
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.4.0
Thread model: posix
$
$ c++ -ggdb -std=c++11 -stdlib=libc++ -Wall -pedantic -O0 -c file.cpp
$ c++ -ggdb -std=c++11 -stdlib=libc++ -Wall -pedantic -O0 file.o -o program
And then debug as follows, it crashes when I try to p str.size():
$ gdb program
GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Wed Feb 6 22:51:23 UTC 2013)
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 ... done
(gdb) br file.cpp:8
Breakpoint 1 at 0x100000d80: file file.cpp, line 8.
(gdb) run
Starting program: /Users/mjbshaw/School/cs6640/2/program
Reading symbols for shared libraries ++............................. done
Breakpoint 1, main (argc=1, argv=0x7fff5fbffab0) at file.cpp:8
8 std::cout << str << std::endl; // Breakpoint here
(gdb) p str.size()
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
std::__1::operator<< <char, std::__1::char_traits<char>, std::__1::allocator<char> > (__os=#0x7fff5fc3d628, __str=#0x1) at string:1243
1243
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__is_long() const) will be abandoned.
If I don't run this in gdb, I get no crash and it works fine (but I need gdb to debug my program). Also, if I remove -std=c++11 -stdlib=libc++ from the compiling options, then it works fine (even in gdb), but I need C++11 for my program.
Are there some known issues with gdb and C++11 (specifically libc++)? I know libc++ and libstdc++ can cause issues if used together, but I'm not trying to use them together (at least not consciously; all I want to use is libc++). Am I specifying some compilation options wrong? Is there a way to properly compile for C++11 on OS X and still be able to debug properly?
GDB 6.3 is almost nine years old. That's just about eternity in Internet years. The product has improved greatly since then. Updating to the last stable release is a must for every developer.

File format not recognized with GNU gdb 6.4 on Solaris 10

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?