loading gdb source for a shared library - c++

i'm using gdb 7.2 on ubuntu 10.10
while stepping with step i get to a point that looks (literally) like this:
0x00130a2c in boost::contexts::context::impl_t::impl_t(void (*)(void*), void*, unsigned int, boost::contexts::context::impl_t*, std::auto_ptr<boost::contexts::context::allocator_base>) () from /home/lurscher/third_party/boost_1_45_0/stage/lib/libboost_context.so.1.45.0
So i want now to associate the appropiate source files; which likely should be on /home/lurscher/third_party/boost_1_45_0/boost/context and /home/lurscher/third_party/boost_1_45_0/libs/context.
But the truth is i'm not sure how to achieve this, its been years since i had to debug in terminal mode

You can compile the third-party library with debugging symbols, and those debugging symbols will chain [i.e. if your app is compiled with debugging symbols, you can step through and see the source lines even within the library]
boost jam takes a debug argument which will instruct it to build a debug version.
in gcc, debug symbols is -g

If your library is compiled in the debug mode, but GDB just doesn't find the sources, you should use the dir command to add the source directory to the search list.

Related

How to build an EABI shared library the same way that it's built on the o/s

Here's my problem:
Trying to debug a C++ program in gdb, but bt won't produce a complete backtrace. It's getting stuck on the Glib shared library, which has been built without any debug info and without -frecord-gcc-switches - this is how it comes as part of the o/s.
I want to build the shared library exactly the same, but with debug info. How can I do this? Building it with Meson shows several other shared libraries and packages that will influence its contents depending on their presence, and there's also of course different compile time flags I can use.
Is there an easy way to ensure the version I build from source produces the same object file as that packaged with linux (plus debug info)?
I've used apt-get source glib2.0-0 and it gives me all the meson files, ninja files and help files I appear to need, but it doesnt quite say this is how it comes as part of Raspberry Pi O/S.

g++ linker error despite specifying the lib files [duplicate]

I use c++11, but also some libraries that are not configured for it, and need some type conversion. In particular I need a way to convert std::__cxx11::string to regular std::string, but googling I can't find a way to do this and putting (string) in front does not work.
If I do not convert I get linker errors like this:
undefined reference to `H5::CompType::insertMember(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long, H5::DataType const&) const'
Is it possible that you are using GCC 5?
If you get linker errors about undefined references to symbols that involve types in the std::__cxx11 namespace or the tag [abi:cxx11] then it probably indicates that you are trying to link together object files that were compiled with different values for the _GLIBCXX_USE_CXX11_ABI macro. This commonly happens when linking to a third-party library that was compiled with an older version of GCC. If the third-party library cannot be rebuilt with the new ABI then you will need to recompile your code with the old ABI.
Source: GCC 5 Release Notes/Dual ABI
Defining the following macro before including any standard library headers should fix your problem: #define _GLIBCXX_USE_CXX11_ABI 0
If you can recompile all incompatible libs you use, do it with compiler option
-D_GLIBCXX_USE_CXX11_ABI=1
and then rebuild your project. If you can't do so, add to your project's makefile compiler option
-D_GLIBCXX_USE_CXX11_ABI=0
The define
#define _GLIBCXX_USE_CXX11_ABI 0/1
is also good but you probably need to add it to all your files while compiler option do it for all files at once.
When I had similar issue it's happened because my lib was build using clang++, and it's linked to libstdc++.so by default on my system. While app binary was build using clang and linked with -lc++ option.
Easiest way to check dependencies is to perform ldd libName.so
To fix it you should use the same library on in app and library.
Easiest way. Build library using clang++ and compile app using clang++. Without extra linking options on both steps. Default stdlib will be used.
Build library with -stdlib=c++ and compile app with -lc++. In this case both library and app will use libc++.so.
Build library without extra options and link binary to -lstdc++. In this case both library and app will use libstdc++.so.
Answers here mostly focus on short way to fix it, but if that does not help, I'll give some steps to check, that helped me (Linux only):
If the linker errors happen when linking other libraries, build those libs with debug symbols ("-g" GCC flag)
List the symbols in the library and grep the symbols that linker complains about (enter the commands in command line):
nm lib_your_problem_library.a | grep functionNameLinkerComplainsAbout
If you got the method signature, proceed to the next step, if you got no symbols instead, mostlikely you stripped off all the symbols from the library and that is why linker can't find them when linking the library. Rebuild the library without stripping ALL the symbols, you can strip debug (strip -S option) symbols if you need.
Use a c++ demangler to understand the method signature, for example, this one
Compare the method signature in the library that you just got with the one you are using in code (check header file as well), if they are different, use the proper header or the proper library or whatever other way you now know to fix it
I got this, the only way I found to fix this was to update all of mingw-64 (I did this using pacman on msys2 for your information).
For me -D_GLIBCXX_USE_CXX11_ABI=0 didn't help.
It works after I linked to C++ libs version instead of gnustl.
I had a similar issue recently while trying to link with the pre-built binaries of hdf5 version 1.10.5 on Ubuntu 16.04. None of the solutions suggested here worked for me, and I was using g++ version 9.1. I found that the best solution is to build the hdf5 library from source. Do not use the pre-built binaries since these were built using gcc 4.9! Instead, download the source code archives from the hdf website for your particular distribution and build the library. It is very easy.
You will also need the compression libraries zlib and szip from here and here, respectively, if you do not already have them on your system.
In my case, I was having a similar problem:
/usr/bin/ld: Bank.cpp:(.text+0x19c): undefined reference to 'Account::SetBank(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)' collect2: error: ld returned 1 exit status
After some researches, I realized that the problem was being generated by the way that Visual Studio Code was compiling the Bank.cpp file. So, to solve that, I just prompted the follow command in order to compile the c++ file sucessful:
g++ Bank.cpp Account.cpp -o Bank
With the command above, It was able to linkage correctly the Header, Implementations and Main c++ files.
OBS: My g++ version: 9.3.0 on Ubuntu 20.04
I've encountered similar problems
It turns out my project was using gcc 7 and g++ 9 and tried to link together object files compiled by those two and it all messed up.
Make sure you use the same compiler versions in all your project.

Converting std::__cxx11::string to std::string

I use c++11, but also some libraries that are not configured for it, and need some type conversion. In particular I need a way to convert std::__cxx11::string to regular std::string, but googling I can't find a way to do this and putting (string) in front does not work.
If I do not convert I get linker errors like this:
undefined reference to `H5::CompType::insertMember(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long, H5::DataType const&) const'
Is it possible that you are using GCC 5?
If you get linker errors about undefined references to symbols that involve types in the std::__cxx11 namespace or the tag [abi:cxx11] then it probably indicates that you are trying to link together object files that were compiled with different values for the _GLIBCXX_USE_CXX11_ABI macro. This commonly happens when linking to a third-party library that was compiled with an older version of GCC. If the third-party library cannot be rebuilt with the new ABI then you will need to recompile your code with the old ABI.
Source: GCC 5 Release Notes/Dual ABI
Defining the following macro before including any standard library headers should fix your problem: #define _GLIBCXX_USE_CXX11_ABI 0
If you can recompile all incompatible libs you use, do it with compiler option
-D_GLIBCXX_USE_CXX11_ABI=1
and then rebuild your project. If you can't do so, add to your project's makefile compiler option
-D_GLIBCXX_USE_CXX11_ABI=0
The define
#define _GLIBCXX_USE_CXX11_ABI 0/1
is also good but you probably need to add it to all your files while compiler option do it for all files at once.
When I had similar issue it's happened because my lib was build using clang++, and it's linked to libstdc++.so by default on my system. While app binary was build using clang and linked with -lc++ option.
Easiest way to check dependencies is to perform ldd libName.so
To fix it you should use the same library on in app and library.
Easiest way. Build library using clang++ and compile app using clang++. Without extra linking options on both steps. Default stdlib will be used.
Build library with -stdlib=c++ and compile app with -lc++. In this case both library and app will use libc++.so.
Build library without extra options and link binary to -lstdc++. In this case both library and app will use libstdc++.so.
Answers here mostly focus on short way to fix it, but if that does not help, I'll give some steps to check, that helped me (Linux only):
If the linker errors happen when linking other libraries, build those libs with debug symbols ("-g" GCC flag)
List the symbols in the library and grep the symbols that linker complains about (enter the commands in command line):
nm lib_your_problem_library.a | grep functionNameLinkerComplainsAbout
If you got the method signature, proceed to the next step, if you got no symbols instead, mostlikely you stripped off all the symbols from the library and that is why linker can't find them when linking the library. Rebuild the library without stripping ALL the symbols, you can strip debug (strip -S option) symbols if you need.
Use a c++ demangler to understand the method signature, for example, this one
Compare the method signature in the library that you just got with the one you are using in code (check header file as well), if they are different, use the proper header or the proper library or whatever other way you now know to fix it
I got this, the only way I found to fix this was to update all of mingw-64 (I did this using pacman on msys2 for your information).
For me -D_GLIBCXX_USE_CXX11_ABI=0 didn't help.
It works after I linked to C++ libs version instead of gnustl.
I had a similar issue recently while trying to link with the pre-built binaries of hdf5 version 1.10.5 on Ubuntu 16.04. None of the solutions suggested here worked for me, and I was using g++ version 9.1. I found that the best solution is to build the hdf5 library from source. Do not use the pre-built binaries since these were built using gcc 4.9! Instead, download the source code archives from the hdf website for your particular distribution and build the library. It is very easy.
You will also need the compression libraries zlib and szip from here and here, respectively, if you do not already have them on your system.
In my case, I was having a similar problem:
/usr/bin/ld: Bank.cpp:(.text+0x19c): undefined reference to 'Account::SetBank(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)' collect2: error: ld returned 1 exit status
After some researches, I realized that the problem was being generated by the way that Visual Studio Code was compiling the Bank.cpp file. So, to solve that, I just prompted the follow command in order to compile the c++ file sucessful:
g++ Bank.cpp Account.cpp -o Bank
With the command above, It was able to linkage correctly the Header, Implementations and Main c++ files.
OBS: My g++ version: 9.3.0 on Ubuntu 20.04
I've encountered similar problems
It turns out my project was using gcc 7 and g++ 9 and tried to link together object files compiled by those two and it all messed up.
Make sure you use the same compiler versions in all your project.

Debugging a dylib in Xcode that was built without debug symbols

I am building a C++ application in Xcode 5 that links to external dynamic libraries (OpenCV 2.4.6, installed via macports). These dynamic libraries appear to have been compiled without debugging symbols, since, when I hit an error in them, I can't see the source code; all I see is assembly code.
I have separately downloaded the OpenCV source code from the OpenCV web site. Is there a way for me to tell Xcode where to look for the source files for the dylibs so that I can step through the OpenCV code in the Xcode debugger?
No, this isn't possible. When a library is compiled with debugging support, additional data is bundled into the shared library which contains a mapping along the lines of "address 0x00240008 corresponds to main.c:24", "address 0x0024001a corresponds to main.c:25", etc. If the modules were built without debugging support, the files are now simply binary blobs that contain machine code and the debugger has no way to translate the machine language back into the source code.
However, since you have the source code, you can recompile the library to include that information and install your custom version. For OpenCV, this will be a command like this:
cmake -DCMAKE_BUILD_TYPE:=Debug .

Can you retrieve source from a debug-compiled binary?

I was digging around and found an executable for something I wrote in Visual C++ 6.0 about 8 years ago. I never backed up the source code, but I think I always compiled everything in debug mode. I also vaguely remember hearing somewhere that "you can't decompile an executable into source code unless you have your compiler's debugging symbols or something." The code would have sentimental value, but its not mission-critical that I retrieve it.
That's the background; here are the questions:
How do I check if an executable was compiled in debug mode or not?
If it is, what information comes with a debug mode executable?
Can I retrieve full source code? Failing that, can I get any substantial improvement when decompiling compared to a release version? If so, how?
Thanks,
-- Michael Burge
I do not believe there is a flag though you might find something by using PEDUMP which will dump out COFF file formats (Windows EXE and DLLs). You can infer if an executable was compiled for debug rather quickly by running Dependecy Walker and seeing if your EXE is linking to any debug DLLs (suffixed with D, e.g. MSVCRT5D.DLL).
FYI in VC6 Debug and Release are simple named builds, not modes per say, each build a collection of compiler and linker settings. The EXE is just code, debug exes normally not having been optimized which makes using a debugger with it easy (versus debugging optimized code). Thus you can compile a Release binary with Debug Symbols which is sometimes useful for tracking down optimized code errors.
Debug EXEs and DLLs did not contain any debugging information but instead had a sidecar PDB file that resided in the same folder and contains all the debugging symbols information that was produced during compilation.
No, source is source and not compiled into the symbols file or executables. There are some amazing decompilers out there that can regenerate decent C versions of your code but they are amazing only in how good the C is, not in how well they can recreate your source.
With Visual Studio, I am afraid you can't, since the debug executable doesn't contain the source. Visual Studio generates pdb files that only contains the mapping between the binary and the sources filenames and line numbers, but you still need the source code with them. That might be different with gcc, which I think integrate the source itself inside the binaries.
I think that many disassemblers can show the source if a binary is compiled in debug mode. For example, I use OllyDBG and it has an option to show the source, although I've never tried.