[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: LD_PRELOAD and mixed architectures
In Message <53A6F6D7.5040300%grammatech.com@localhost>,
Dave Vitek <dvitek%grammatech.com@localhost>wrote:
=>I'm on an amd64 machine that has a mixture of i386 and amd64 binaries
=>present. I want to build a shared object file and use LD_PRELOAD to
=>inject it into every process in some process tree. The executables in
=>the tree could be a mixture of amd64 and i386 executables. Many other
=>operating systems have a way of using LD_PRELOAD in a mixed architecture
=>environment, but I'm not seeing a path to victory on netbsd.
=>I had a look at the source code for ld.so (the elf one anyway). It
=>doesn't search search LD_LIBRARY_PATH -- it just tries to open() the
=>filename in LD_PRELOAD relative to CWD and blows up if the architecture
=>doesn't match the process. Other operating systems facilitate this sort
=>of thing in various ways:
=>Solaris: LD_PRELOAD_32 and LD_PRELOAD_64
=>Linux: Search LD_LIBRARY_PATH, only fail if every attempt fails. Also,
=>"$LIB" is magical.
=>Mac OS X: Universal binaries
=>One (ugly) thought I had is to have the shared object file hook every
=>function in the "exec" family and fix LD_PRELOAD so it points at the
=>architecture of the binary about to be exec'd before delegating to the
=>real exec. Anyone have a less ugly alternative that doesn't require
=>modifying system files (e.g., adjusting ld.so)?
Just a thought, but have you tried putting a 32-bit version of
the library under /emul/netbsd32 ?
Main Index |
Thread Index |