Re: How to use a different ld-linux.so?

[Paul D. Smith]

%% John Reiser <jreiser@BitWagon.com> writes:

  >> I have a need to use a different runtime linker (ld-linux.so) for some
  >> of my applications.  I _don't_ want to change the executables themselves
  >> (changing the path to the runtime linker in the ELF image for example).

  jr> Why not?  http://www.BitWagon.com/rtldi/rtldi.html

The main reason is because I don't have easy write access to the
binaries.  Also, those same binaries are being used inside a UML
instance, where they want the "normal" path to the runtime linker... I
don't want to have to edit the ELF image to swap them back and forth.

The rtldi tool looks interesting, but I'm not sure it will work in our
environment: we really need a way of choosing at runtime, not link time,
what the pathname to the linker will be.

I'm curious, since you need to specify which runtime linker you want at
link time anyway, what's the advantage of rtldi over just specifying the
alternative linker directly with -Wl,--dynamic-linker at link time?
IOW, in your example on the web page, why not just say:

    ... -Wl,--dynamic-linker=/2.2.4-24/ld-linux.so.2 ...

instead of invoking /2.2.4-24/rtldi ?  I see that the latter sets up the
library path properly so you don't have to set LD_LIBRARY_PATH, but are
there other differences as well?

  >> * Debugging: I can't debug because I can't find a way to convince GDB
  >> to invoke the program-to-be-debugged using an alternative runtime
  >> linker.

  jr>   $ gdb /lib/ld-linux.so.2
  jr>   (gdb) run --library-path /lib /bin/date
  jr> If you want to set breakpoints then put one near the end of
  jr> _dl_start_user where it invokes _dl_init_internal.  Inspect
  jr> /proc/<pid>/maps to find out what has been mapped, then use the
  jr> add-symbol-file command of gdb.  Find the offset from "objdump
  jr> --section-headers a.elf | grep text" then add the base from the
  jr> map of the address space.

Oy!  I need something simpler than that.  This is going to be a commonly
used environment.  We could look into doing that through a GDB init
script or something I guess.

  >> ... another idea is to use LD_PRELOAD to install a private version
  >> of the execve() system call, which would set the alternative
  >> ld-linux.so as the first argument.

  jr> By using LD_PRELOAD one can supersede the visible uses of execve()
  jr> [the ones that use global symbol linkage to invoke execve()], but
  jr> there can be "bare" system calls that do not use symbols.

Yes, true.  I wonder how prevalent those are.  Certainly none of our
code uses a bare system call.


I tried this using a simple replacement that just printed an extra
string than ran the native execve(), and that at least worked:

  $ /bin/sh -c '/bin/echo hi'
  hi

  $ LD_PRELOAD=libexecshim.so.1.0 /bin/sh -c '/bin/echo hi'
  woot woot!
  hi

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@nortelnetworks.com>   HASMAT--HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.