Re: FW: cannot debug multi-threaded programs with gdb/gdbserver

[Daniel Jacobowitz <dan@debian.org>]

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