I am able to compile and run an executable that uses C++ boost graph library (BGL) on OSX 10.8.3.
But when I try to debug using either gdb or Xcode the debugger is unable to find symbols defined in the BGL header file adjacency_list.hpp.
I looked at the file and tried different namespaces
boost::in_degree
boost::detail::in_degree
But debuggers could not find symbols.
It seems the function is inlined and the information is lost.
I tried another function (add_vertex) with same result.
I compile the code using CMake with the flag -DCMAKE_BUILD_TYPE=Debug and I am able to print other symbols.
Please suggest how can I fix this.
// Trying using
(gdb) print boost::detail::in_degree
No symbol "in_degree" in namespace "boost::detail".
(gdb) print boost::detail::in_degree(0, *pGraph)
No symbol "in_degree" in namespace "boost::detail".
(gdb) print boost::in_degree(0, *pGraph)
No symbol "in_degree" in namespace "boost".
// Trying using boost::
(gdb) pt boost::in_degree
No symbol "in_degree" in namespace "boost".
(gdb) pt boost::in_degree(0, *pGraph)
No symbol "in_degree" in namespace "boost".
Related
I'm trying to call a function with
(gdb) call fun()
in a 3rd party library libFoo which I get in compiled form with stripped symbols.
(gdb) info function ^fun$
Non-debugging symbols:
0x00007ffff6d7e3b0 fun
Problem is, there is an unrelated system library libBar loaded which also has fun in it, a variable this time, and gdb prefers that symbol instead of the desired one. I suspect that this is because this hit is a non-stripped debugging symbol.
(gdb) info var ^fun$
File ../bar/baz.c:
256: static const int fun[18];
(gdb) info symbol fun
fun in section .rodata of libBar.so
It's a bit crazy that it tries to call variable as a function, but that's what it tries to do.
The question is, how do I disambiguate the symbol and instruct gdb to use one from libFoo ?
So far, the only way I found requires a manual step (info function ^fun$ above) and then call (void)0x00007ffff6d7e3b0(). This isn't too good because it doesn't allow me to script the call across different program runs.
I've got a question regarding using one of the GCC linker options: -Wl,--defsym.
Some time ago I decided to rewrite one of my projects in C++ but without using its standard library and without even linking to it (I compile .cpp source files to object files using C++ compiler but I link them using C compiler).
For that I used following compiler flags:
-fno-exceptions -fno-rtti -nostdlib -nodefaultlibs
And following linker options:
-Wl,--defsym -Wl,__cxa_pure_virtual=0
Using those flags I got my shared library compiling and linking fine.
But after I try to use my shared library in some simple program (also compiled and linked using above flags) I get following error while running it:
examples/bin/blink: symbol lookup error: examples/bin/libblink.so: undefined symbol: __cxa_pure_virtual
where blink is the name of the executable and libblink.so is the name of my shared library.
I tried to fix it and it looks like replacing --Wl,--defsym linker flag (for both executable and library) with this function:
extern "C" void __cxa_pure_virtual
{
while (true);
}
does the job. Why is the --Wl,--defsym not working in this case?
I'd also like to mention that I tested this under Windows and it works fine there.
I think that I've found an answer to my question.
Changing the symbol address from 0 to any other value fixes my issue.
So instead of having:
--Wl,--defsym --Wl,__cxa_pure_virtual=0
I have:
--Wl,--defsym --Wl,__cxa_pure_virtual=1
This way runtime linker does not look for a symbol (which I think is the case when the address is set to 0).
DISCLAIMER: I'm not an expert or professional and am simply teaching myself. So my attempts to solve this may have been rudimentary at best.
In C++, whenever I try to compile a program using the <cmath> library, compiling will complete, but when the program attempts to execute I get a runtime error. A Windows dialogue box pops up saying the program has stopped working and is searching for a solution. Instead of just asking you folks, I figured I would try to learn a bit and give it my best shot first. So I loaded up GDB and tried running the program with that to shed a little more light on what is going on.
When running a program including the <cmath> library, GDB immediately outputs the following (regardless of where I place the breakpoint):
warning: Could not load shared library symbols for C:\Program Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\AE_MailSensor_Plugin.dll.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for C:\Program Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\ame_outlooksensor.dll.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for C:\Program Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\ame_smtpsensor.dll.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for C:\Program Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\OS_Plugin.dll.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for C:\Program Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\COM_sensor.dll.
Do you need "set solib-search-path" or "set sysroot"?
If I place the breakpoint on main it stops here. If I allow it to run without a breakpoint or instruct GDB to move to the next step I receive:
Program received signal SIGSEGV, Segmentation fault.
0x6fc85cd1 in libstdc++-6!_ZNSo9_M_insertIdEERSot_ ()
from C:\Users\Me\Desktop\libstdc++-6.dll
From what I can gather, it looks like for some reason my system is having an issue loading the <cmath> library, but I'm still not really sure why. The first three warnings look like files related to e-mail processes, but that makes very little sense to me (but again I don't know very much). So that's about where I'm stuck.
FYI: I am running Windows 7 enterprise, using MinGW and G++ for my compiler.
EDIT: I have tried compiling the program with debug symbols enabled by using -g. When doing this the backtrace is reduced to only #0, #1, and #2 (see comment below for original backtrace) with #2 appended by `at C:\Users\me\desktop\file.cpp: 19. Indicating line 19 which is the last step before the method. This case is repeated in more simple programs with the line indicated being the last step before a method is called.
Is it possible there is a version issue going on akin to this question which points to this forum thread? I'm using gcc version 4.8.1
EDIT: per request of #pm100.
code:
#include <cmath>
#include <iostream>
using namespace std;
int main() {
cout << floor(2.3);
}
for compiling: (i am using notepad++)
NPP_SAVE
CD $(CURRENT_DIRECTORY)
C:\mingw\bin\g++ "$(FULL_CURRENT_PATH)" -o "$(NAME_PART).exe" -g
cmd /c $(NAME_PART).exe
When I get the callstack from gdb, I only get function names and source file information.
(gdb) f
#0 main (argc=1, argv=0xbffff1d4) at main.c:5
I don't get which Shared Library or Application the function belongs to.
On Windows, Windbg or Visual Studio will show callstacks with "myDll!myFunc" format, which shows you which module the function belongs to.
Currently in gdb I'm using "info address [function]" to get the address of the function symbol, and then use "info share" to manually find the range in which the function lies in memory to determine which library it is in.
Anyway to see the library directly without this manual process?
You can use info symbol. It prints a library name for a function.
Like this:
(gdb) info symbol f
f(double) in section .text of libmylib_gcc.so
(gdb) info symbol printf
printf in section .text of /lib64/libc.so.6
I am using g++ 4.1.2 and gdb 7.2
I am debugging code that uses Xerces, which I built using the same tools, though presumably without debugging.
GDB steps through my code just fine, but of course does NOT step through Xerces because it probably doesn't have debugging information, and definitely does not know where the source directory is. But all I want is to set a breakpoint when Xerces (a callback parser) calls a callback object.
Their base class is DefaultHandler
I have a class ContentHandlerBase : public DefaultHandler
Then leaf classes inherit from ContentHandlerBase. These leaf classes are inside namespace A, for example
in gdb I try to set a breakpoint.
b A::LeafContentHandler::LeafContentHandler
b A::LeafContentHandler::endElement
The first breakpoint works because the code is inline (defined in the header).
The second breakpoint does not work, meaning gdb claims that no such symbol exists, even though it obviously does. It is a virtual function defined in the Xerces library, if that makes a difference. Before I recompiled Xerces, it was built with g++3.4.6 and I could not find the symbol in gdb. Now, gdb finds the symbol (I can hit tab) but then it says it doesn't exist, should I wait for a library to load.
Can anyone tell me what I have to do to make it work? I'd prefer not to build all of xerces with debugging.
Note that in some cases, with the constructor in the .cpp file, it also worked for some reason, and then, because it was in the same file, I could set a subsequent breakpoint at linenumber, and that worked.
Try gdb 7.1 - it seems there are some problems in setting breakpoint by function name in gdb 7.2