This is an example of how you might set up a directory hierarchy to debug
core files from various systems and architectures on your desktop machine.
The best method is to debug a core file on the same type of CPU, and under
the identical version of the operating system, as the system which generated
the crash in the first place.  Sometimes this is not possible (if, for example,
you are debugging something that occurred on a remote system and you don't have
ready access to a similar setup).

In this case, you can "fake out" the utilities by running the version of the
command which is appropriate for the architecture and OS release, along with
the correct libraries for that setup.  Remember that software is generally
backwards compatible, in that an old program will run on a newer release of
the system.  This means if you set up the "kas" directory hierarchy on a
Solaris 2.3 machine, you should be able to debug most crashes from 2.3 and
earlier Solaris 2 releases, plus SunOS 4.x crashes (by running in Binary
Compatibility mode).  You wouldn't be able to debug a 2.4 core file.

In order to do this, you will need to define a set of directories for each
OS version and architecture.  A sample 5.3/sun4m setup is included (without
many actual files, but check the READMEs to see what should get put there).

Under the 'adb' directory, define subdirectories for each OS version which you
might need (in other words, create a directory for all the versions of the OS
which you currently run on any machine): 4.1.3, 5.3, 5.4, etc.  Under each
OS directory, define a subdirectory for each architecture (sun4m, sun4c, etc)
which you have running that OS version.  Under each architecture, put the
binaries of the commands from each release.  The best thing to do is copy the
executables from the /usr/bin or /bin directories on the running systems
into this hierarchy.  Then copy the needed libraries into a 'lib' directory,
the appropriate macros into the 'macros' directory, and edit the 'kas' script
in ./bin to define the location of this adb hierarchy.


WARNING:  This process generally gives good results.  There have been cases
where binary compatibility fails, or where cores are not readable.  If you
obtain results that look wrong, or if the utilities don't run correctly,
do your analysis on the system that died instead of using this procedure.
