Hello, i think the order to search libraries: 1st sysroot 2nd host-sysroot (absolute path of lib on host) 3rd solib-search-path for cross debugging is not usable. In this case libraries of the host-sysroot replace the libraries for cross target in solib-search-path, and debugging becomes impossible. I configured GDB with --with-sysroot, declared additional set sysroot, set solib-search-path, set solib-absolute-path (nevermind alias of set sysroot). Example: Simple Hello world project, additional lib freetype and jpeg (they should exists host-sysroot), linked to binary. Gdb session started with init: set sysroot <TOOLCHAIN> set solib-search-path <SPECIAL LIBS> #include "stdio.h" int main(int argc, char **argv) { printf("test"); } Invoking: Cross GCC Compiler arm-1136jfs-linux-gnueabi-gcc -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.c" ../main.c: In function 'main': ../main.c:5:1: warning: control reaches end of non-void function Finished building: ../main.c Building target: gdb_bug_sysroot Invoking: Cross GCC Linker arm-1136jfs-linux-gnueabi-gcc -L/home/opt/amklibs/arm-1136jfs -o "gdb_bug_sysroot" ./main.o -lz -ljpeg -lfreetype Finished building target: gdb_bug_sysroot GDB-Session: ... 252,189 =library-loaded,id="/usr/lib/libz.so.1",target-name="/usr/lib/libz.so.1",host-name="/home/opt/libs/arm-1136jfs/libz.so.1",symbols-loaded="0",thread-group="i1" 252,190 &"warning: `/usr/lib/libjpeg.so.8': Shared library architecture unknown is not compatible with target architecture arm.\n" 252,190 =library-loaded,id="/usr/lib/libjpeg.so.8",target-name="/usr/lib/libjpeg.so.8",host-name="/usr/lib/libjpeg.so.8",symbols-loaded="0",thread-group="i1" 252,190 =library-loaded,id="/lib/libc.so.6",target-name="/lib/libc.so.6",host-name="/home/opt/Toolchain/arm-1136jfs-linux-gnueabi/gcc-4.5.2-glibc-2.13-binutils-2.21-kernel-2.6.36-sanitized/sysroot-arm-1136jfs-linux-gnueabi/lib/libc.so.6",symbols-loaded="0",thread-group="i1" 252,190 &"warning: `/lib/libgcc_s.so.1': Shared library architecture unknown is not compatible with target architecture arm.\n" 252,190 =library-loaded,id="/lib/libgcc_s.so.1",target-name="/lib/libgcc_s.so.1",host-name="/lib/libgcc_s.so.1",symbols-loaded="0",thread-group="i1" ... The library libz loaded correctly from solib-search-path. The library libc.so.6 loaded correctly from Toolchain by sysroot. The libjpeg and libfreetype (cut out of log) loaded incorrectly from host rootfs instead of solib-search-path. Thanks for a request.
I'm guessing this use case wasn't originally considered, because it doesn't look like how set sysroot/solib-search-path are meant to be used. (gdb) help set solib-search-path Set the search path for loading non-absolute shared library symbol files. ^^^^^^^^^^^^ This takes precedence over the environment variables PATH and LD_LIBRARY_PATH. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This command is there mostly to help targets like Windows that don't report to the debugger the full path to the shared library. GNU/Linux always works with full patchs, such as "/usr/lib/libjpeg.so.8". The normal use of "set sysroot" is to point that at a directory that contains _all_ the libraries the target reports as loaded (or simply, the copy of the target's whole root filesystem). IOW, make the sysroot wholly self contained (you can use symlinks though), and forget about solib-search-path. Or, with GDB >= 7.0, point the sysroot at "remote:", and GDB will fetch the libraries from the target automatically (but won't work in the end if you strip the copies of the libraries on the target, as GDB will work with the stripped copies then).
I've got this information from http://sourceware.org/gdb/onlinedocs/gdb/Files.html. "... `solib-search-path' is used after `sysroot' fails to locate the library, OR if the path to the library is relative instead of absolute." I've got a cross-toolchain (must stay untouched) as sysroot, which is not serving all libraries (additional jpeg, ...). So i could give a hint to GDB to a special folder(solib-search-path) _after_ sysroot. That was my idea to use solib-search-path, but pity it isn't available. So this is not a bug, rather unprecise points in the online documentation of solib-search-path. Thanks for the advices.
I'm still confused, because of your answer: Set the search path for loading non-absolute shared library symbol files. This takes precedence over the environment variables PATH and LD_LIBRARY_PATH. GNU/Linux always works with full paths, such as "/usr/lib/libjpeg.so.8" and this print: 252,189=library-loaded,id="/usr/lib/libz.so.1",target-name="/usr/lib/libz.so.1",host-name="/home/opt/libs/arm-1136jfs/libz.so.1",symbols-loaded="0",thread-group="i1" Here i see the search order, once Linux reports absolute "/usr/lib/libz.so.1" and it is not available on sysroot(1st), PATH(2nd) and LD_LIBRARY_PATH(3rd). It will cut off "/usr/lib/" and replace with _solib-search-path_(4th) to "/home/opt/libs/arm-1136jfs/libz.so.1". Both are absolute: libz.so.1 => /usr/lib/libz.so.1 (0x40026000) libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0x40041000) Why he do this stripping for libz.so.1 and not for libjpeg.so.8? Can anyone tell me the source file/function, where it is implemented?
solib.c:solib_find
The issue has been identified now, and a patch should land on mainline soon. Sorry for not having clearly understood the issue sooner. http://sourceware.org/ml/gdb-patches/2012-09/msg00665.html
CVSROOT: /cvs/src Module name: src Changes by: emachado@sourceware.org 2012-09-28 20:20:10 Modified files: gdb : ChangeLog solib.c Log message: 2012-09-28 Nathan Miller <nathanm2@us.ibm.com> Edjunior Machado <emachado@linux.vnet.ibm.com> PR gdb/13989 * solib.c (solib_find): Prevent GDB from loading native libraries when debugging a cross-target corefile. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.14722&r2=1.14723 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/solib.c.diff?cvsroot=src&r1=1.166&r2=1.167
Fix is in.