I'm working on getting set with Eclipse CDT for some embedded development and I'm having difficulty getting source level debugging working for static libraries.
I'm using my own Makefiles, so that is my first suspect right now, especially since gdb claims that no symbol table info is available for the functions with no source. When using a static library, is the debugging information from the library usually included in the ELF file from the final link stage? Right now I can see the full source/assembly mix if I point objdump -S at the .a file, but none of the debug info makes it into the .elf. The debugging info/source is present for the main application. Am I missing some switch to tell ld to include this?
Otherwise, what is the best way to get gdb to tell me what is looking for (and failing to find) with regard to debug information for a specific function.
Figured it out.
The lesson is very simple: always, always, triple check your makefiles.
Was still linking in an old copy of the static library built without debugging information.
I would guess that GDB is simply not finding the source files that go with that debug information. See http://web.mit.edu/gnu/doc/html/gdb_9.html#SEC51 for documentation on how to tell it where to find source files.
Related
This is for my company, so I'm leery of being too specific, but I'll try.
I am attempting to add support for some existing ANSI C code to our platform. I am using GCC 4.7.2 as well as the GNU linker. We use part of newlib, but also some other C libraries, specifically libc.a. The end goal of this is to get an EXE or ELF image (this is for a PowerPC architecture micro) to put into the micro's RAM. This is being done on Windows XP. I am simply using a batch file, not a build environment or toolchain.
One of my build errors is a multiple definition problem of malloc/free functions. The cmd window spits out the error that there are definitions of these in both malloc.o and mallocr.o. Both of these are within libc.a. I've been told the "r" in mallocr.o is for reentrancy. I've also been told our platform does not support reentrancy.
I'm trying to resolve this error by preventing the linking of mallocr.o from within libc.a. This is the part where I am lost, I don't know how to do this. Google hasn't turned up anything helpful, and I haven't found a question on this site yet that answers my problem. I don't know if this is even possible.
There is really no specific code snippet to include in this question. Below is the error from the cmd window. I've *'d out company specific things I am not comfortable sharing.
c:\***\platform\2_2_0_r2013-2_x86-32\tools\gcc_4_7_2\ppc\bin\..\powerpc-eabi\lib\libc.a(mallocr.o): In function `free':
mallocr.c:(.text+0x19c): multiple definition of `free'
c:\***\platform\2_2_0_r2013-2_x86-32\tools\gcc_4_7_2\ppc\bin\..\powerpc-eabi\lib\libc.a(malloc.o):malloc.c:(.text+0x28): first defined here
c:\***\platform\2_2_0_r2013-2_x86-32\tools\gcc_4_7_2\ppc\bin\..\powerpc-eabi\lib\libc.a(mallocr.o): In function `malloc':
mallocr.c:(.text+0x468): multiple definition of `malloc'
c:\***\platform\2_2_0_r2013-2_x86-32\tools\gcc_4_7_2\ppc\bin\..\powerpc-eabi\lib\libc.a(malloc.o):malloc.c:(.text+0x0): first defined here
I've been trying to compile balsa the email reader on ubuntu (i'm new to the whole process of compiling an open source project directly from sources.
so i did the whole configure and make but then I ran into this problem:
error: unknown type name 'gpgme_decrypt_result_t
after doing a little research on the error code.. it turns out that it belongs to gpgme a scary looking encryption library..
what do I do in this case? i hope i'm not expected to go in the code and debug stuff am i?
update:
this question is related to this other question here on the ubuntu forum
Unfortunately, you may be required to delve into the code to figure out why something doesn't build!
In this case however the answer is probably quite simple. The main reasons I would expect a symbol from an external library to not have been defined are:
The library header files do not exist on your system
You have the wrong version of the library header files on your system
The headers exist, but the compiler is not looking in the correct place
Clearly the solutions are similar: you will need to install the correct version of gpgme's header files for this software in the right place. Note that having the library itself installed is not the same as having the headers. In Ubuntu this is evident due to the presence of -dev packages which are the package's header files, and if you look through the repose you will find libgpgme11-dev. I suggest you start by installing this, which will eliminate point 1 above. If it still doesn't work, you'll need to start investigating the other two possibilities.
I am an intermediate C programmer who is learning his way around. I recently learned using GDB (forced to actually) and also am doing some code using Ptrace.
I was browsing through some code on ptrace and came across "DEBUG INFO".
I want to know what this means and when should I include this in my code?
What are debug info files?
I couldnt find much from google and wiki related to this. There is no wiki for that tag too.
May be if you can point me to the right direction I can repay by writing one.
DEBUG_INFO you are referring to is probably just an option (and define) of linux kernel. Enabling it when configuring kernel tells compiler to include debug information in resulting binary. This debug information itself is just additional data, that allows debuggers (and other tools like strace, addr2line, gprof, ...) relate binary code it's executing to source it was compiled from (source lines, variable names, etc, etc). You can find more details on debug information in general starting at DWARF (popular debug data format).
check for what is a core dump .you might get some directions.
The whole credit goes to Peter for the answer.
Initially I went through "What is core dump"
Then I came across the following link which actually tells the difference between
Debug Build
Release build
which is: debug build includes debug information while a release built doesn't have these and is Optimized code.
Also this answer can help you get more information.
I would like to have control over the type of the libraries that get found/linked with my binaries in CMake. The final goal is, to generate binaries "as static as possible" that is to link statically against every library that does have a static version available. This is important as would enable portability of binaries across different systems during testing.
ATM this seems to be quite difficult to achieve as the FindXXX.cmake packages, or more precisely the find_library command always picks up the dynamic libraries whenever both static and dynamic are available.
Tips on how to implement this functionality - preferably in an elegant way - would be very welcome!
I did some investigation and although I could not find a satisfying solution to the problem, I did find a half-solution.
The problem of static builds boils down to 3 things:
Building and linking the project's internal libraries.
Pretty simple, one just has to flip the BUILD_SHARED_LIBS switch OFF.
Finding static versions of external libraries.
The only way seems to be setting CMAKE_FIND_LIBRARY_SUFFIXES to contain the desired file suffix(es) (it's a priority list).
This solution is quite a "dirty" one and very much against CMake's cross-platform aspirations. IMHO this should be handled behind the scenes by CMake, but as far as I understood, because of the ".lib" confusion on Windows, it seems that the CMake developers prefer the current implementation.
Linking statically against system libraries.
CMake provides an option LINK_SEARCH_END_STATIC which based on the documentation: "End a link line such that static system libraries are used."
One would think, this is it, the problem is solved. However, it seems that the current implementation is not up to the task. If the option is turned on, CMake generates a implicit linker call with an argument list that ends with the options passed to the linker, including -Wl,-Bstatic. However, this is not enough. Only instructing the linker to link statically results in an error, in my case: /usr/bin/ld: cannot find -lgcc_s. What is missing is telling gcc as well that we need static linking through the -static argument which is not generated to the linker call by CMake. I think this is a bug, but I haven't managed to get a confirmation from the developers yet.
Finally, I think all this could and should be done by CMake behind the scenes, after all it's not so complicated, except that it's impossible on Windows - if that count as complicated...
A well made FindXXX.cmake file will include something for this. If you look in FindBoost.cmake, you can set the Boost_USE_STATIC_LIBS variable to control whether or not it finds static or shared libraries. Unfortunately, a majority of packages do not implement this.
If a module uses the find_library command (most do), then you can change CMake's behavior through CMAKE_FIND_LIBRARY_SUFFIXES variable. Here's the relevant CMake code from FindBoost.cmake to use this:
IF(WIN32)
SET(CMAKE_FIND_LIBRARY_SUFFIXES .lib .a ${CMAKE_FIND_LIBRARY_SUFFIXES})
ELSE(WIN32)
SET(CMAKE_FIND_LIBRARY_SUFFIXES .a ${CMAKE_FIND_LIBRARY_SUFFIXES})
ENDIF(WIN32)
You can either put this before calling find_package, or, better, you can modify the .cmake files themselves and contribute back to the community.
For the .cmake files I use in my project, I keep all of them in their own folder within source control. I did this because I found that having the correct .cmake file for some libraries was inconsistent and keeping my own copy allowed me to make modifications and ensure that everyone who checked out the code would have the same build system files.
I've been trying to make GNU gdb 6.5-14 to use the source code embedded on the object file when debugging, instead of scanning some directories for it.
The main reason is that I develop for an embedded platform and I cross compile, which means that all the source is in my computer.
I read about the -ggdb3 flag, that includes a lot of extra info, including the source code. So I started compiling with that flag.
Doing a objdump -S src/lib/libfoo.so indeed prints out all the source code with the assembly code intermixed with the source code, so I'm guessing that it does indeed contain that info.
The only thing is that GDB does not print it, unless I run from a nfs mounted version of my workspace that contains the source.
Does anyone know how can I instruct gdb to look in the object file for code instead of relying on external files?
Employed Russian is correct -- gcc never embeds source code in object files.
What it does do (with any -g setting) is add paths to where the source file can be found.
GDB can use these paths to find the source files. And if you happen to set up the exact same paths on your embedded file system as the paths where you keep your source code on the host system, you can trick gdb into finding them.
Your guess about what -ggdb3 does is totally incorrect; the object files do not contain the source. You can prove that by running 'strings -a libfoo.so'.
Your best bet is to learn how to use remote debugging -- you can then use GDB from host (which has access to all the sources); with an added advantage that you need much less memory on target. See gdbserver in "info gdb".