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
