How to make GDB verbose about its solib search process - gdb

I'm having trouble making GDB load a particular library as a replacement for a library used in a core file.
How can I make so GDB list which paths it tries for each library? Something like set debug auto-load on, but for shared libraries.

I'm having trouble making GDB load a particular library as a replacement for a library used in a core file.
GDB will look up absolute paths it obtains from the core.
Because of this, setting solib-search-path is ineffective, and only setting sysroot or solib-absolute-prefix is.
In addition, you need to set sysroot or solib-absolute-prefix before loading the core. That is, this works:
gdb -ex 'set sysroot /tmp/sysroot' -ex 'file a.out' -ex 'core core'
whereas this doesn't (sysroot setting happens after the file and core are already loaded):
gdb -ex 'set sysroot /tmp/sysroot` a.out core
How can I make so GDB list which paths it tries for each library?
There doesn't appear to be such an option. In particular, set debug solib on doesn't actually help here. Using trunk GDB:
gdb/gdb
GNU gdb (GDB) 14.0.50.20230115-git
...
(gdb) set debug solib on
(gdb) file /tmp/a.out
Reading symbols from /tmp/a.out...
(gdb) core /tmp/core
[New LWP 29158]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `./a.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000401116 in main () at crash.c:3
3 return *ip;
(gdb)
You can determine where GDB is looking for shared libraries by running it under strace:
strace -e open,openat -o /tmp/strace.out gdb/gdb -ex quit /tmp/a.out /tmp/core
In /tmp/strace.out:
...
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=29289, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
openat(AT_FDCWD, "/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/tmp/a.out", O_RDONLY|O_CLOEXEC) = 9
openat(AT_FDCWD, "/tmp/a.out", O_RDONLY|O_CLOEXEC) = 9
openat(AT_FDCWD, "/tmp/a.out", O_RDONLY) = 9
openat(AT_FDCWD, "/tmp/core", O_RDONLY|O_CLOEXEC) = 9
openat(AT_FDCWD, "/tmp/a.out", O_RDONLY|O_CLOEXEC) = 10
openat(AT_FDCWD, "/tmp/a.out", O_RDONLY) = 10
openat(AT_FDCWD, "/tmp/a.out", O_RDONLY|O_CLOEXEC) = 11
openat(AT_FDCWD, "/usr/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 11
openat(AT_FDCWD, "/usr/lib64/libc.so.6", O_RDONLY) = 11
openat(AT_FDCWD, "/usr/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/usr/lib64/ld-linux-x86-64.so.2", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/usr/lib64/ld-linux-x86-64.so.2", O_RDONLY) = 12
openat(AT_FDCWD, "/usr/lib64/ld-linux-x86-64.so.2", O_RDONLY|O_CLOEXEC) = 13
...

Related

Clang++ updated, can't find certain headers despite them being in the include directory

So I'm on mac and wanted to experiment with the latest llvm release, without having to wait for them to be passed on the xcode command line tools.
So I downloaded the LLVM 10 release pre-built binary from their downloads page, and stuck it in a folder called llvm. So the clang executable can be found in ~/SDKs/LLVM/bin.
I make this program:
#include <string>
#include <iostream>
int main(int argc, char const *argv[])
{
std::string myString("Hello World");
std::cout << myString;
return 0;
}
and run:
~/SDKs/Clang+LLVM10/bin/clang++ main.cpp
I get this fatal error:
~/SDKs/Clang+LLVM10/bin/../include/c++/v1/string.h:60:15: fatal error:
'string.h' file not found
#include_next <string.h>
^~~~~~~~~~
Which doesn't make sense because I can find string.h manually using finder, and it's right there in the folder that is quoted in the error.
I'm guessing this has something to do with clang++ searching my system include path first, finding an older string.h there and so choosing not to use the updated string.h, causing an error?
Some additional info if it helps:
Running this (the new compiler)
~/Programming/SDKs/Clang+LLVM10/bin/clang++ -Wp,-v -E -xc -x c++ /dev/null
Gives me:
clang -cc1 version 10.0.0 based upon LLVM 10.0.0 default target x86_64-apple-darwin18.7.0
ignoring nonexistent directory "/usr/include/c++/v1"
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
~/SDKs/Clang+LLVM10/bin/../include/c++/v1
/usr/local/include
~/SDKs/Clang+LLVM10/lib/clang/10.0.0/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
# 1 "/dev/null"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 393 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "/dev/null" 2
Running (this is the default compiler with that comes with my mac)
clang++ -Wp,-v -E -xc -x c++ /dev/null
gives me
clang -cc1 version 11.0.0 (clang-1100.0.33.17) default target x86_64-apple-darwin18.7.0
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
# 1 "/dev/null"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 374 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "/dev/null" 2
I also encountered this error. And after my a digging out, I found the reason:
The include_next is a gnu compiler extension, seems it does not exist in clang. Although clang(/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++) has packaged the original std lib under directory:
“ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/“, but as compile source codes from Apple Mac, generally it always specifies the system root path by option “-isysroot”, generally the command is like this:“-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk”
, to overwrite the default std lib search path.
So maybe you must overwrite the default sys root to ensure right std lib to be linked.

CMake on MSYS2 freezes up

I'm running MSYS2 on Windows 8, and having problems with CMake freezing / locking up.
Here's a minimal example:
main.cpp:
#include <iostream>
int main()
{
std::cout << "Hello World!" << std::endl;
return 0;
}
CMakeLists.txt:
cmake_minimum_required(VERSION 3.0.0)
project (helloworld)
add_executable(helloworld main.cpp)
If I open the MSYS2 console, go to the directory in which both of the above files are located, and execute the command
cmake .
there is no further output and the console locks up. An empty CMakeFiles folder is created, but nothing else happens. I've tried with CMake 3.10.2 and 3.2.3 and the same happens for both versions.
Below is some straceoutput if at all of interest:
If I run the command
strace cmake .
I get different output at different times. Sometimes the final line is something like
19 4436 [main] cmake 2320 child_copy: done
Sometimes it is something like
44 239509 [main] cmake 9820 open_shared: name cygpid.10668 n 10668, shared 0xBB0000 (wanted 0x0), h 0x344, *m 6
And sometimes the end of the output is something like
20 2735480 [main] cmake 14200 kill_pgrp: killing pid 5900, pgrp 5900, p->ctty /dev/pty0, ctty /dev/pty5
24 2735504 [main] cmake 14200 sig_send: 1 = SetNamedPipeHandleState (0x358, PIPE_NOWAIT, NULL, NULL)
16 2735520 [main] cmake 14200 sig_send: sendsig 0x358, pid 5900, signal 17, its_me 0
19 2735539 [main] cmake 14200 sig_send: Not waiting for sigcomplete. its_me 0 signal 17
24 2735563 [main] cmake 14200 sig_send: returning 0x0 from sending signal 17
23 2735586 [main] cmake 14200 _pinfo::kill: 0 = _pinfo::kill (17), pid 5900, process_state 0x4C5
20 2735606 [main] cmake 14200 kill_pgrp: killing pid 15152, pgrp 15152, p->ctty /dev/pty5, ctty /dev/pty5
3486 2739092 [main] cmake 14200 sig_send: 1 = SetNamedPipeHandleState (0x3A0, PIPE_NOWAIT, NULL, NULL)
44 2739136 [main] cmake 14200 sig_send: sendsig 0x3A0, pid 15152, signal 17, its_me 0
33 2739169 [main] cmake 14200 sig_send: Not waiting for sigcomplete. its_me 0 signal 17
27 2739196 [main] cmake 14200 sig_send: returning 0x0 from sending signal 17
25 2739221 [main] cmake 14200 _pinfo::kill: 0 = _pinfo::kill (17), pid 15152, process_state 0x61
What could be the reason for these problems?
EDIT:
The output of
cmake . --trace
is as follows, before it freezes:
Running with trace output on.
d/Dropbox/Programming/Cplusplus/workspace/Testprograms/test_cmake/CMakeLists.txt(1): cmakeminimum_required(VERSION 3.0.0 )
d/Dropbox/Programming/Cplusplus/workspace/Testprograms/test_cmake/CMakeLists.txt(2): project(helloworld )
usr/share/cmake-3.10.2/Modules/CMakeDetermineSystem.cmake(36):
if(CMAKE_HOST_UNIX )
usr/share/cmake-3.10.2/Modules/CMakeDetermineSystem.cmake(37): find_program(CMAKE_UNAME uname /bin /usr/bin /usr/local/bin )
usr/share/cmake-3.10.2/Modules/CMakeDetermineSystem.cmake(38): if(CMAKE_UNAME)
usr/share/cmake-3.10.2/Modules/CMakeDetermineSystem.cmake(39): if(CMAKE_HOST_SYSTEM_NAME STREQUAL AIX )
usr/share/cmake-3.10.2/Modules/CMakeDetermineSystem.cmake(45): else()
usr/share/cmake-3.10.2/Modules/CMakeDetermineSystem.cmake(46):
exec_program(${CMAKE_UNAME1 ARGS -r OUTPUT_VARIABLE CMAKE_HOST_SYSTEM_VERSION )
CMake doesn't like in tree builds. Make a separate build folder.
mkdir build
cd build
cmake ..
CMake doesn't build your programs, it only creates build files. Your next step would be.
mingw32-make
Unless you have other issues, you should be able to run your program.
Mike

Error while loading shared libraries: foo.so: cannot open shared object file: No such file or directory

I have cross compiled c++ code for raspberry pi.
Below is process i followed,
1 ) Cloned the official toolchain from raspberry pi github ( URL : https://github.com/raspberrypi/tools )
Set the environment variable of arm-linux-gnueabihf-c++ ( in .bashrc file )
3 ) Typed this command for generating binary for ARM architecture
arm-linux-gnueabihf-g++ ./test.cpp -L. -lfoo -o test
4 ) Binary is successfully generated now. I tried to run the binary with below commands but had no luck with it.
LD_PRELOAD=/home/pi/Downloads/linux-sdk-demo-arm/foo.so ./test
LD_LIBRARY_PATH=/home/pi/Downloads/linux-sdk-demo-arm ./test
even i set the environment variable in .bashrc file but having no luck
It gives the below errors respectively,
ERROR: ld.so: object './foo.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
./test: error while loading shared libraries: foo.so: cannot open shared object file: No such file or directory
AND
./test: error while loading shared libraries: foo.so: cannot open shared object file: No such file or directory
I'm sure the foo.so file is there at the right path but it can not find it.Here's the directory structure,
-rw-rw-r-- 1 pi pi 15263 Jan 9 17:23 cp5200api.h
-rw-rw-r-- 1 pi pi 1110 Mar 6 12:17 dtype.h
-rwxrwxrwx 1 pi pi 152751 Mar 9 13:43 foo.so
-rw-rw-r-- 1 pi pi 512 Mar 12 08:42 Makefile
-rw-rw-r-- 1 pi pi 1285 Mar 8 20:13 notplugged
-rw-rw-r-- 1 pi pi 1285 Mar 8 20:13 plugged
-rwxr-xr-x 1 pi pi 13228 Mar 12 08:42 test
-rw-rw-r-- 1 pi pi 2204 Mar 6 15:22 test.cpp

cmake searching for shared libraries in invalid paths

I noticed that the cmake generation step in my project was taking a long time and so I ran cmake through strace to figure out the root cause. I found that cmake was trying to find internal shared libraries in the wrong locations repeatedly, which was causing a lot of unnecessary file system lookups. Here is a simple project that illustrates the problem:
$ ll -R
.:
total 20K
drwxr-xr-x 2 mark mark 4.0K May 25 16:22 alpha
drwxr-xr-x 2 mark mark 4.0K May 25 16:22 beta
drwxr-xr-x 2 mark mark 4.0K May 25 16:42 build
-rw-r--r-- 1 mark mark 185 May 25 16:20 CMakeLists.txt
-rw-r--r-- 1 mark mark 0 May 25 16:16 dummy.cc
drwxr-xr-x 2 mark mark 4.0K May 25 16:22 gamma
./alpha:
total 4.0K
-rw-r--r-- 1 mark mark 0 May 25 16:16 alpha.cc
-rw-r--r-- 1 mark mark 69 May 25 16:20 CMakeLists.txt
./beta:
total 4.0K
-rw-r--r-- 1 mark mark 0 May 25 16:16 beta.cc
-rw-r--r-- 1 mark mark 67 May 25 16:18 CMakeLists.txt
./build:
total 0
./gamma:
total 4.0K
-rw-r--r-- 1 mark mark 35 May 25 16:19 CMakeLists.txt
-rw-r--r-- 1 mark mark 0 May 25 16:16 gamma.cc
alpha.cc, beta.cc, gamma.cc and dummy.cc are all empty cc files. Here are the contents of all the CMakLists.txt files:
Top level CMakeLists.txt
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
add_subdirectory(alpha)
add_subdirectory(beta)
add_subdirectory(gamma)
add_executable(dummy_exec dummy.cc)
target_link_libraries(dummy_exec alpha)
alpha/CMakeLists.txt
$ cat alpha/CMakeLists.txt
add_library(alpha SHARED alpha.cc)
target_link_libraries(alpha beta)
beta/CMakeLists.txt
$ cat beta/CMakeLists.txt
add_library(beta SHARED beta.cc)
target_link_libraries(beta gamma)
gamma/CMakeLists.txt
$ cat gamma/CMakeLists.txt
add_library(gamma SHARED gamma.cc)
I invoke cmake (through strace) as follows:
$ cd build/
$ strace -f -o /tmp/s.out cmake ..
-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/mark/Downloads/cmake/build
When I inspect the strace output, I see it trying to access libalpha in invalid locations (such as under the beta/ and gamma/ sub directories):
31430 access("/home/mark/Downloads/cmake/build/beta/libalpha.so", R_OK) = -1 ENOENT (No such file or directory)
31430 access("/home/mark/Downloads/cmake/build/gamma/libalpha.so", R_OK) = -1 ENOENT (No such file or directory)
Similarly, it is trying to access libbeta and libgamma in invalid locations:
31430 access("/home/mark/Downloads/cmake/build/alpha/libbeta.so", R_OK) = -1 ENOENT (No such file or directory)
31430 access("/home/mark/Downloads/cmake/build/gamma/libbeta.so", R_OK) = -1 ENOENT (No such file or directory)
31430 access("/home/mark/Downloads/cmake/build/alpha/libgamma.so", R_OK) = -1 ENOENT (No such file or directory)
31430 access("/home/mark/Downloads/cmake/build/beta/libgamma.so", R_OK) = -1 ENOENT (No such file or directory)
For a large project with many shared libraries and many dependencies, these invalid lookups add up and seem to be causing big delays at the makefile generation step. Any idea on why this is happening and how I could prevent cmake from searching in these invalid paths ?

How do you properly install SOCI?

I'm facing an annoying problem that has been holding me back from programming for some time. I intend to start a personal project in which I need to use a database to store certain information and I decided to use SQLite however I did not like the C-ish API so I came across SOCI wrapper in the SQLite wiki.
I went to the official SOCI website, read the documentation and decided to give it a go. I followed the instructions in the 'Installation' chapter of the documentation and after installing all requirements I compiled it and installed it with:
cmake -DWITH_BOOST=ON -DSOCI_TESTS=ON -DWITH_SQLITE3=ON
make
make test
sudo make install
All tests completed successfully however when trying to run (after compiling with g++ test.cpp -o1 -lsoci_core -lsoci_sqlite3) a program such as this one:
test.cpp:
#include "soci/soci.h"
#include "soci/sqlite3/soci-sqlite3.h"
#include <iostream>
int main()
{
soci::session sql(soci::sqlite3, "testdb.db");
return 0;
}
I get an error saying: "Error while loading shared libraries: libsoci_sqlite3.so.3.1: cannot open shared object file: No such file or directory." but looking at the install log I can clearly see that the shared library is installed.
I believe I have found the issue. Doing a:
strace -e open ./1 2>&1 | grep soci
Outputs the following:
open("/usr/local/lib/libsoci_core.so.3.1", O_RDONLY) = 3
open("/lib/x86_64-linux-gnu/tls/x86_64/libsoci_sqlite3.so.3.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/tls/libsoci_sqlite3.so.3.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/x86_64/libsoci_sqlite3.so.3.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libsoci_sqlite3.so.3.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/tls/x86_64/libsoci_sqlite3.so.3.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/tls/libsoci_sqlite3.so.3.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/x86_64/libsoci_sqlite3.so.3.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libsoci_sqlite3.so.3.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/tls/x86_64/libsoci_sqlite3.so.3.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/tls/libsoci_sqlite3.so.3.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/x86_64/libsoci_sqlite3.so.3.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/libsoci_sqlite3.so.3.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/x86_64/libsoci_sqlite3.so.3.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/libsoci_sqlite3.so.3.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64/libsoci_sqlite3.so.3.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libsoci_sqlite3.so.3.1", O_RDONLY) = -1 ENOENT (No such file or directory)
./1: error while loading shared libraries: libsoci_sqlite3.so.3.1: cannot open shared object file: No such file or directory
By looking at it you can clearly see that it searches /usr/local/lib/ only for soci_core whereas normally it should search for soci_sqlite3 as well. A quick and dirty hack that fixes the problem is to create a smylink to libsoci_sqlite3.so.3.1 in any of the other folders listed there but I'm quite sure that there is a better way of fixing it.
On your SOCI installation libs are located in /usr/local/lib64/
Following statement should work:
g++ test.cpp -o test -I/usr/local/include/soci -L/usr/local/lib64/ -lsoci_core -lsoci_sqlite3 \
-Wl,-rpath=/usr/local/lib64/