Re: LD_PRELOAD and mixed architectures

["Gary Duzan" <gary%duzan.org@localhost>]

In Message <53A6F6D7.5040300%grammatech.com@localhost>,
   Dave Vitek <dvitek%grammatech.com@localhost>wrote:

=>Hi all,
=>
=>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 ?

                                Gary Duzan