Bug 13989 - gdb invalid search order for shared libraries by cross debuging
Summary: gdb invalid search order for shared libraries by cross debuging
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 7.4
: P2 normal
Target Milestone: 7.6
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-18 11:28 UTC by Daniel
Modified: 2012-09-28 21:10 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel 2012-04-18 11:28:23 UTC
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.
Comment 1 Pedro Alves 2012-04-18 11:45:16 UTC
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).
Comment 2 Daniel 2012-04-18 12:31:59 UTC
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.
Comment 3 Daniel 2012-04-18 12:57:57 UTC
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?
Comment 4 Pedro Alves 2012-05-10 14:31:20 UTC
solib.c:solib_find
Comment 5 Pedro Alves 2012-09-28 19:50:41 UTC
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
Comment 6 cvs-commit@gcc.gnu.org 2012-09-28 20:20:15 UTC
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
Comment 7 Pedro Alves 2012-09-28 21:10:51 UTC
Fix is in.