On Fri, Sep 20, 2002 at 10:38:12AM +0100, Stuart Hughes wrote:

Hi Linda,

I followed the advice from Daniel/Steve and upgraded my toolchain
(binutils-2.13/gcc-2.3/glibc-2.2.5/).  Now I can do some thread aware
gdb/gdbserver debug.  

It seems to work fine on simple programs, but on some other large
applications some behaviour is not predictable (this may well be the
application, as it issues SIGSTOP/SIGCONT to control threads, and I
think this causes gdb to get confused).

This should not confuse gdbserver.  I'm not sure what it'll do to
native GDB, but I don't think it'll confuse that either...

set heuristic-fence-post 20		// not sure if this is actually needed
set solib-absolute-prefix /dev/null
set solib-search-path
<path_to_cross_compiled_standard_libs>:<path_to_your_shared_libs>

In my case:
<path_to_cross_compiled_standard_libs> is /usr/local/mipsel-linux

NOTE: no lib component (this is passed back from the location on the
target ???).

<path_to_your_shared_libs>	This is only needed if you have your own
shared libs.

NOTE: The path on the host must contain the basename component, but this
must not be given in the <path_to_your_shared_libs>

For instance, if I build on the host and the library ends up in
/home/seh/project/test/lib, but the library ends up on the target in
/apps/custom/mylibs

You would need to:
- make a symlink on the homst from lib -> mylibs
- set <path_to_your_shared_libs> to /home/seh/project/test

You should not be doing it this way; life will be much easier if you
just set the shared libraries up in the same hierarchy on target and
host and set solib-absolute-prefix /location/of/host/lib/tree.  That
is,
	/location/of/host/lib/tree/lib/ld-2.2.5.so
	/location/of/host/lib/tree/usr/lib/libz.so
et cetera.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer