This question already has answers here:
Could not load shared library symbols for linux-vdso.so.1. while debugging
(2 answers)
Closed 8 years ago.
It might be unrelated to mixing C and C++ code together, but the problem doesn't seem to have a clear answer.
I run into this error when running GDB:
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Inferior 1 (process 1663) exited normally]
You didn't actually ask a question.
You can ignore this message. It's related to some systems reporting something unexpected when gdb tries to open the vdso. I believe newer versions of gdb have a workaround for this.
Related
This question already has answers here:
GCC equivalent of MS's /bigobj
(5 answers)
Closed 1 year ago.
When I was building an application of mine which used Assimp, I got an error
C:\Users\nitin\AppData\Local\Temp\ccA4Vs3q.s: Assembler messages:
C:\Users\nitin\AppData\Local\Temp\ccA4Vs3q.s: Fatal error: can't write 117 bytes to section .text of CMakeFiles\assimp.dir\AssetLib\IFC\IFCReaderGen1_2x3.cpp.obj because: 'File too big'
c:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/as.exe: CMakeFiles\assimp.dir\AssetLib\IFC\IFCReaderGen1_2x3.cpp.obj: too many sections (46774)
C:\Users\nitin\AppData\Local\Temp\ccA4Vs3q.s: Fatal error: can't close CMakeFiles\assimp.dir\AssetLib\IFC\IFCReaderGen1_2x3.cpp.obj: File too big
Nade\vendor\assimp\code\CMakeFiles\assimp.dir\build.make:1965: recipe for target 'Nade/vendor/assimp/code/CMakeFiles/assimp.dir/AssetLib/IFC/IFCReaderGen1_2x3.cpp.obj' failed
So I searched online for solutions and I found a solution that said that I need to set the /bigobj flag.
I am using Cmake and Mingw32-make.
But when I add the definition like this
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /bigobj)
or like that
add_definitions(/bigobj)
I Get the error
/bigobj: No such file or directory
How do I solve this error while solving the Too Big OBJ file error at the same time?
The /bigobj option is for Microsoft Visual Studio compiler.
For GCC, try -Wa,-mbig-obj instead.
If you want to support both, try:
if (MSVC)
add_compile_options(/bigobj)
else ()
add_compile_options(-Wa,-mbig-obj)
endif ()
If you want to specify directly only a single target:
target_compile_options(my_target_name PRIVATE /bigobj)
This question already has answers here:
fatal error LNK1104
(5 answers)
Closed 2 years ago.
This error only happened in Debug mode, what could be? The code is very large, cannot copy to here.
Error LNK1104 cannot open file 'D:\TEST\TEST_Build.exe'
Microsoft documentation says:
The two most common causes of the issue are:
your program is already running or is loaded in the debugger [...]
It lists a few other possibilities, too - please follow the link.
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
I am trying to debug a C++ program in Eclipse using gdb. I think it works fine in my main() function, but elsewhere it gives me a warning when I try to look at the value of a variable:
Failed to execute MI command:
-data-evaluate-expression variable
Error message from debugger back end:
Could not find the frame base for "Class::method()".`
After scouring the internet, I am having a hard time understanding what this error means or finding out how to fix the problem. There are a few other similar questions (here and here) floating around Stack Overflow.
Since Apple's Xcode command line tools are painfully out-of-date (see gcc and gdb issues) I needed to use my own homebrewed versions. I don't know if there is something in the setup for these tools that I might have missed.
I can debug from command line using gdb and I hit the same error: "Could not find the frame base for "Class::method()", so I'm pretty sure it is not an issue with Eclipse.
Does anything jump out to anyone, that might be causing this problem?
Mac OS X 10.8.5 (Mountain Lion)
Eclipse 4.2.1 (Juno)
gcc 4.8.2 (homebrewed) (with -O0 and -g3)
gdb 7.6.2 (homebrewed and codesigned)
Update:
I am also seeing the line:
BFD: /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork(i386:x86-64): unknown load command 0x20
Followed by several warnings:
warning: Could not open OSO archive file "/private/tmp/gcc48-KqoQ/gcc-4.8.2/build/x86_64-apple-darwin12.5.0/libstdc++-v3/src/../libsupc++/.libs/libsupc++convenience.a"
warning: Could not open OSO archive file "/private/tmp/gcc48-KqoQ/gcc-4.8.2/build/x86_64-apple-darwin12.5.0/libstdc++-v3/src/../src/c++11/.libs/libc++11convenience.a"
warning: Could not open OSO archive file "/private/tmp/gcc48-KqoQ/gcc-4.8.2/build/x86_64-apple-darwin12.5.0/libstdc++-v3/src/../src/c++98/.libs/libc++98convenience.a"
warning: `/private/tmp/gcc48-KqoQ/gcc-4.8.2/build/x86_64-apple-darwin12.5.0/libstdc++-v3/src/.libs/compatibility-atomic-c++0x.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc48-KqoQ/gcc-4.8.2/build/x86_64-apple-darwin12.5.0/libstdc++-v3/src/.libs/compatibility-c++0x.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc48-KqoQ/gcc-4.8.2/build/x86_64-apple-darwin12.5.0/libstdc++-v3/src/.libs/compatibility-chrono.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc48-KqoQ/gcc-4.8.2/build/x86_64-apple-darwin12.5.0/libstdc++-v3/src/.libs/compatibility-debug_list-2.o': can't open to read symbols: No such file or directory.
...
which continues for several lines. Google searches for "gdb bfd unknown load command" reveal a lot of sites without any solution, but they all seem to indicate that there may be a conflict between non-apple versions of gdb and Mac OS X 10.8+.
Any insight would help a ton!
It's because the name mangling. Names are mangled same with GCC and Clang (they often share similar mechanisms). Name mangling makes it available to have C/C++ method and Assembly procedure with the same name. See what happens to a C definition:
void myfunc() {}
We use nm to view binary names of symbols. Use nm --demangle to view unmangled names. Nm output for compiled file is:
...
0000000000000000 T _myfunc
...
Number of other symbols depends on debugging level, see GCC manpage for -O and -g options. As we see, there is a number. It's hexadecimal. It has eight digits on 32bit machines and sixteen digits on 64bit machines (it's because n-bit CPU means that n-bits represent a pointer, the symbol is really a pointer inside the binary file). Then we have symbol type. Only two values are interesting now: T is a C/C++/... method, t is an assembler procedure. See what goes on if we compile following assembly code:
myproc:
GCC and Clang shouldn't push debugging symbols when compiling Assembly, so nm output will probably look like:
0000000000000000 t myproc
Assembly procedure names are not mangled. C++ is mangled, very strangely. Some characters, like : or , are not allowed in symbol name. Compile this C++ source:
namespace myspace { void myfunc() {} }
We see output:
...
0000000000000000 T __ZN7myspace6myfuncEv
...
And main method name is never mangled. If we have like this:
int main(int argc, char** argv) {}
int main(std::vector<std::string> args) {}
only the second name is mangled. I think this may be the problem. And, these warnings mean NOTHING. They mean that system was recompiled with low debugging symbol count.
I am currently writing a small library, and I want to check it for leaks (among other things); however, for some reason, gdb is not loading the library symbols. I have read many other posts on here (and various other places on the internet) about this, however, I cannot seem to find a solution. Here is what is going on:
I am compiling the shared library with the following flags (these are included in both the final shared library as well as all object files):
CFLAGS=-Wall -O0 -g -fPIC
Likewise, I am compiling the binary memtest (the client application for the library) to check for memory leaks and such with these flags
CFLAGS=-Wall -O0 -g
Now, I inserted a NULL pointer into the library to test if I could trace through it and "debug" the pointer (i.e. it's making it crash). So I try to run it through gdb, but it's a no go. The output of info sharedlibrary is the same for both the executable and the core:
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
... Some libraries I am not worried about debugging...
0x00d37340 0x00d423a4 Yes (*) /home/raged/MyLIB/memtest/../lib/libMyLIB.so.0 <--- My lib
.... and some more....
(*): Shared library is missing debugging information.
As you can see, it's not loading the debug information. I am uncertain as to why this is. I have built and linked everything with the -g flag, and I even try -ggdb and -g3 but nothing seems to work properly. When I load in a core dump, this is what I see:
...some libs...
Reading symbols from /home/raged/MyLIB/memtest/../lib/libMyLIB.so.0...done.
Loaded symbols for /home/raged/MyLIB/memtest/../lib/libMyLIB.so.0
Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols found)...done.
...some more libs...
Notice how my library does not give a (no debugging symbols found) error - anyone have any ideas why? As I said before, I am unable to debug this through running the program gdb ./memtest or through debugging the core file.
Thanks for your help.
EDIT It may also be important to note, that (if you didn't realize by path) this library is a local shared library (i.e. I'm using -Wl,-rpath to link/load it)
EDIT2 It seems my version of GDB was out-of-date. Now, I have updated to the latest version from the CVS server (I have also tried latest release version 7.2) and it can "load" symbols. My info sharedlibrary now reads this:
0x00e418b0 0x00e4be74 Yes /home/raged/MyLIB/memtest/../lib/libMyLIB.so.0
However, I am still unable to step through any functions (in the shared library) - anyone have any ideas?
EDIT3 I have also tried to step through linking against a static library (libMyLIB.a) but it still isn't working. My OS is CentOS 5.6; does anyone know of any issues with this system? Also, just another confirmation that my symbols are being loaded (it just can't step through any shared lib function for some reason)
(gdb) sharedlibrary MyLIB
Symbols already loaded for /home/raged/MyLIB/memtest/../lib/libMyLIB.so.0
I found the reason this wasn't working: I was calling an old function call to initialize a pointer in my test executable. Since the object was never being created, I could never step into the library. Once I updated the function call, all worked well.
That said, if anyone experiences similar issues while all symbols appear to be loaded, be sure to check that all pointers are initialized properly even if they have the correct type.