From: Greg Thain (thain@sunquest.UUCP)
Date: 02/27/93


From: thain@sunquest.UUCP (Greg Thain)
Subject: Re: IMPORTANT Re: How do I safely back out of Libc4.3 ?
Date: 28 Feb 1993 01:14:33 GMT

In article <C30urH.511@boulder.parcplace.com> imp@boulder.parcplace.com (Warner Losh) writes:
>Maybe it is time for an LD_LIBRARY_PATH variable that you can set in
>your shell that tells the dynamic libraries where to load from. This
>would allow you to do a trial installation and back it out if things
>went badly w/o the effort of backing up your system. I know on Suns
>it has saved my butt more times that I care to think about.
>
>Warner
>
>P.S. I might have missed it in the docs, so please be gentle if I
>have overlooked something.
>--
>Warner Losh imp@boulder.parcplace.COM ParcPlace Boulder
>I've almost finished my brute force solution to subtlety.

There are other tasks this could be used for as well. Several people have
asked for the functionality of trace, or truss. These are commands which
enable system call level tracing of binaries for which one has no source.

Instead of providing this functionality at the kernel level, one could have
an alternate libc.so.x.y with wrappers around all the system calls,
printing out their calling parameters and the return values. This method
could also allow for tracing at the C library level, which you can't do
with trace or truss. If there were such a libc.so.x.y, one could stick it
in, say, /lib/debug/libc.so.x.y, set the LD_LIBRARY_PATH (or equivalent)
to /lib/debug, and away you go. Simple, no kernel changes, and
flexible.