Hanning wrote:
> Rie,
>
> I have actually done what you described when compiling the binary, using
> LD_OPTIONS to specify a different ld.so.1. I am a little unclear about your
> post regards libc_psr.so.1. When you said it is auxiliary, does it mean it
> is only used if libc.so.1 is not found in the LD_LIBRARY_PATH or it is
> referenced first rather than libc.so.1? If it is the later then I am worried
> as I don't want anything anything loaded from within the machine itself, only
> from the library I have included in the cd.
>
> Bart,
>
> I appreciate your comment, however as I stated on my original post my
> intention here is to gather a live memory dump before the machine is shutdown
> for the actual analysis.
Rod (rie) meant that libc_psr.so.1 is an auxiliary filter for
libc.so:
> libc_psr.so.1 contains optimizations for libc.so.1, and is referenced as
> an auxiliary filter. This library doesn't need to exist, as the associated
> routines in libc.so.1 act as a fall-back.
You can see this on your own system:
% elfdump -d /lib/libc.so | grep AUX
[2] SUNW_AUXILIARY 0xb7ee
/platform/$PLATFORM/lib/libc_psr.so.1
If libc_psr.so.1 exists on the system, it will get loaded (after libc),
and will supply optimized versions of some functions. The path it gets
loaded from is the one shown in the elfdump output above. If libc_psr.so.1
does not exist, then the generic functions in libc.so.1 will be used.
Note that it's a hardwired path, so LD_LIBRARY_PATH will not affect
this --- it's just going to look at that path.
Rod also mentioned that you can simply turn off the use of the
auxiliary filter:
> So, if you wanted a self contained home for your objects you could:
>
> % cp /lib/libc.so.1 .
> % cp /lib/libm.so.2 .
> % cp /lib/ld.so.1 .
> % LD_OPTIONS=-I./ld.so.1 cc -o memdump memdump.c
> % LD_LIBRARY_PATH=. LD_NOAUXFLTR=yes ./memdump
^^^^^^^^^^^^^
From your description, it sounds like this is what you want to do.
- Ali
