GDB Dynamic Library Search Path

When GDB cannot display information about the so dynamic library or displays incorrect information, usually due to a library search path error, you can specify the library search path using the set Sysroot, set Solib-absolute-prefix, set Solib-search-path.

1. Set Sysroot and set Solib-absolute-prefix are the same command, in fact, set Sysroot is the alias of set Solib-absolute-prefix.

2. Set Solib-search-path sets the search path for the dynamic library, which sets up multiple search paths, separated by ":" Between the paths (colons in Linux, and semicolons in DOS and Win32).

3. The difference between set Solib-absolute-prefix and set Solib-search-path:

Overall, Solib-absolute-prefix sets the absolute path prefix for the library, only valid for absolute paths, while the Solib-search-path sets the search path for the library, which works on both absolute and relative paths. (The compiler automatically links the so library with an absolute path.)

Detailed rules are:

Set Solib-search-path because it is a path prefix, you can set only one path, and Solib-search-path can set multiple search paths.

Coredump encounters two paths when loading dynamic library information: absolute path and relative path. A library that is linked at compile time is usually an absolute path, such as "/lib/libc.so.6", "/lib/libdl.so.2", and so on, which is also saved as an absolute path in the Coredump file, while the so library that the program loads with the Dlopen function may use a relative path, such as "./ libddd.so, the Coredump file saves the same path intact.

For ease of expression, a is used to denote the path of set solib-absolute-prefix settings, and R (a) indicates that a path is removed from the root prefix (that is, the prefix "/" symbol is removed), and the BN represents each path set by the set Solib-search-path. The x represents the library path saved in the Coredump, which is the path to the library file to be searched, and F (x) indicates the file name (the string after the last "/" sign of the path) in x that is removed from the directory.

For absolute paths, the search order is:

1) a/x//Add Solib-absolute-prefix prefix to search, success will not continue, otherwise continue 2)

2) R (A)/X//And then 1) the root prefix is removed after the search, success will no longer continue, otherwise continue 3)

3) bn/r (A)/X//again on the basis of 2) to add each path in the Solib-search-path to search, success will no longer continue, otherwise continue 4)

4) bn/f (X)///only 2) file name (remove the directory segment), and add each path in the Solib-search-path to search, success will no longer continue, otherwise continue 5)

5) $PATH/R (A)/X//on 2) using each path in the environment variable $path to search, the success will no longer continue, otherwise continue 6)

6) $LD _library_path/r (A)/X//on 2) using each path in the environment variable $ld_library_path to search, the success will no longer continue, otherwise continue 7)

7) return failure

For relative paths, the search order is:

1) X//search directly using the original path, success will not continue, otherwise continue 2)

2) bn/x///Add each path in the Solib-search-path to search, success will no longer continue, otherwise continue 3)

3) bn/f (X)//Use only the file name (remove the directory segment), and add each path in the Solib-search-path to search, success will no longer continue, otherwise continue 4)

4) $PATH/x//and then use the environment variable $path each path to search, success will no longer continue, otherwise continue 5)

5) $LD _library_path/x//And then use the environment variable $ld_library_path each path to search, success will no longer continue, otherwise continue 6)

6) return failure

===================================

To illustrate:

Set Solib-absolute-prefix/root/temp

Set Solib-search-path/home/evan:/home/peter

$PATH Is/usr/sbin:/usr/bin

$LD _library_path Is/opt:/usr/games

Then the search order for the absolute path "/lib/libc.so.6" is:

1) a/x

/root/temp/lib/libc.so.6

2) R (A)/X

Root/temp/lib/libc.so.6

3) bn/r (A)/X

/home/evan/root/temp/lib/libc.so.6

/home/peter/root/temp/lib/lic.so.6

4) bn/f (X)

/home/evan/libc.so.6

/home/peter/libc.so.6

5) $PATH/R (A)/X

/usr/sbin/root/temp/lib/libc.so.6

/usr/bin/roo/temp/lib/lic.so.6

6) $LD _library_path/r (A)/X

/opt/root/temp/lib/libc.so.6

/usr/games/root/temp/lib/libc.so.6

The search order for relative path "./libddd.so" is

1) X

./libddd.so

2) bn/x

/home/evan/./libddd.so

/home/peter/./libddd.so

3) bn/f (X)

/home/evan/libddd.so

/home/peter/libddd.so

4) $PATH/x

/usr/sbin/./libddd.so

/usr/bin/./libddd.so

5) $LD _library_path/x

/opt/./libddd.so

/usr/games/./libddd.so

As seen from the above, the absolute path and relative path are one step is to use the file name and Solib-search-path stitching to find (the absolute path of the 4th step and the relative path of the 3rd step), so as long as the set Solib-search-path each library file is located in the direct directory , then you can guarantee that every library can be found.

4. Check if the load path of so library is correct can use the Info sharedlibrary command, if the corresponding file has been found the load address of its from and to will have a value, and the right side of the path shows the address of the loading file, this time, if the so library file contains symbolic information, The value of Syms read is yes, otherwise no, if the corresponding file is not found, the address of the From and to is empty, the value of Syms read is no, at this point the right path shows the path to the library file in the Coredump file.

5. If the "Cannot access memory at address 0x87000069" error occurs during the Coredump file loading process or the Info sharedlibrary command, this is usually due to the primary execution file (" File "command or" exec-file "command) does not match the Coredump (" core "command or" core-file "command). At this point, you should check that the master execution file is the primary execution file used to generate the coredump, as long as it is almost impossible to cause dynamic library information read errors.

6. If the onboarding process has "warning:. Dynamic" section for "/lib/librt.so.1" are not at the expected address (wrong library or version mism Atch?) "Such a hint, this is usually the library search path setting error, GDB loaded the wrong library file caused. At this point, you should use the Info sharedlibrary command to view the loading path of the library and use set Sysroot or set Solib-search-path to modify the search path to fix the wrong library to the correct path.

7. After the search path path is set, it is best to load the main execution file with the file command, and then load the Coredump file with the core command, in order to guarantee the correct loading of the symbol table. Otherwise, if you first load the Coredump file with the core command and then load the main execution file with the file command, the library will simply be searched but not loaded (as you can see with the info sharedlibrary command), and then the core command can be re-executed again.

8. An example of a real search:

Current directory is/home

Master execution file in/HOME/EVAN/GDBSO/MIPS/GDBSO

Core file on/home/evan/gdbso/mips/coredump

The dynamic library used is copied to the same directory as the master execution file

The standard library used to compile the master execution file is copied to the main executable file in the Lib directory/home/evan/gdbso/mips/lib/libxxx.so

Enter GDB and load the main execution file with the file command:

[Email protected]:/home$ mips-linux-gnu-gdb
...
(gdb) file Evan/gdbso/mips/gdbso
Reading symbols From/home/evan/gdbso/mips/gdbso...done.
(GDB) Info sharedlibrary
No GKFX Libraries loaded at this time.

You can see that the dynamic library information is not available when you load only the master execution file.

Then load the Coredump file with the core command:

(GDB) Core Evan/gdbso/mips/coredump
...
Warning:. Dynamic section for "/lib/libc.so.6" isn't at the expected address (wrong library or version mismatch?)
...
(GDB) Info sharedlibrary
From to Syms Read Shared Object Library
0X2AAD98C0 0x2aadd6d8 yes/lib/librt.so.1
0x2aaf3460 0x2ab0db98 yes/lib/libm.so.6
0X2AB7E2E0 0x2ab89b28 yes/lib/libpthread.so.0
0X2ABBA9A0 0x2acb2bd8 yes/lib/libc.so.6
0x2ad06a40 0x2ad07988 yes/lib/libdl.so.2
No/lib/ld.so.1
No./libddd.so
(GDB)

After you have both the master execution file and the Coredump file, you can see the dynamic library information with info sharedlibrary. However, there are hints that the library version does not match during the onboarding process. The info Sharedlibrary also sees gdb mistakenly loading the standard library that comes with the system.

We set the absolute path to a nonexistent directory to see the original path name saved in Coredump:

(GDB) Set sysroot/noexist
...
(GDB) Info sharedlibrary
From to Syms Read Shared Object Library
No/lib/librt.so.1
No/lib/libm.so.6
no/lib/libpthread.so.0
No/lib/libc.so.6
No/lib/libdl.so.2
No/lib/ld.so.1
No./libddd.so
(GDB)

The original path saved in Coredump is named/lib/librt.so.1, and in order for GDB to use the correct library/home/evan/gdbso/mips/lib/librt.so.1, you only need to set the absolute path prefix to/home/evan/ Gdbso/mips, this is set to evan/gdbso/mips to demonstrate the effect:

(GDB) Set Sysroot evan/gdbso/mips
...
(GDB) Info sharedlibrary
From to Syms Read Shared Object Library
0X2AAD98C0 0x2aade270 Yes evan/gdbso/mips/lib/librt.so.1
0x2aaf3110 0x2ab31b70 Yes evan/gdbso/mips/lib/libm.so.6
0x2ab7e320 0x2ab8e620 Yes evan/gdbso/mips/lib/libpthread.so.0
0x2abba6a0 0x2accc3f0 Yes evan/gdbso/mips/lib/libc.so.6
0x2ad06b50 0x2ad07c70 Yes evan/gdbso/mips/lib/libdl.so.2
0x2aaa8810 0x2aac2e40 Yes evan/gdbso/mips/lib/ld.so.1
No./libddd.so
(GDB)

As you can see, GDB has loaded the absolute path correctly. But the relative path "./libddd.so" has not yet been found, in order to use/home/evan/gdbso/mips/libddd.so, set the library search path to include/home/evan/gdbso/mips. To see the effect, a non-existent search path was added:

(GDB) Set solib-search-path/noexist:/home/evan/gdbso/mips
...
(GDB) Info sharedlibrary
From to Syms Read Shared Object Library
0X2AAD98C0 0x2aade270 Yes evan/gdbso/mips/lib/librt.so.1
0x2aaf3110 0x2ab31b70 Yes evan/gdbso/mips/lib/libm.so.6
0x2ab7e320 0x2ab8e620 Yes evan/gdbso/mips/lib/libpthread.so.0
0x2abba6a0 0x2accc3f0 Yes evan/gdbso/mips/lib/libc.so.6
0x2ad06b50 0x2ad07c70 Yes evan/gdbso/mips/lib/libdl.so.2
0x2aaa8810 0x2aac2e40 Yes evan/gdbso/mips/lib/ld.so.1
0x2ad1a590 0x2ad1a770 yes/home/evan/gdbso/mips/libddd.so
(GDB)

As you can see, all the libraries have found the correct path, and the syms is loaded correctly.

Source: http://blog.csdn.net/_xiao/article/details/23289971

GDB Dynamic Library Search Path