"/lib/ld-linux.so.2 /usr/bin/emacs" fails: "Memory exhausted"

[Mark Seaborn <mseaborn@onetel.com>]

The problem can be summarised very simply:

$ /lib/ld-linux.so.2 /usr/bin/emacs
Memory exhausted--use M-x save-some-buffers RET
$ emacs --version
GNU Emacs 21.4.1
...

In other words, starting GNU Emacs by invoking the dynamic linker
doesn't work, and fails pretty quickly with an incorrect out-of-memory
error.

This is on i386.

This is the first program I've seen that fails when starting using the
dynamic linker this way.  I would like this to work because Plash
(http://plash.beasts.org) launches programs this way.

The only reference to this problem that I have seen is a note in a
Linux kernel patch:

  [SPARC]: Adjust 32-bit ELF_ET_DYN_BASE.

  We were using 0x08000000 instead of TASK_UNMAPPED_BASE
  so that running something like "/lib/ld-linux.so.2 emacs"
  would work.

  The issue there was that wherever /lib/ld-linux.so.2 gets
  mapped (controlled by ELF_ET_DYN_BASE), that is where the
  BSS start for the process ends up.  Now, emacs allocates
  dynamic memory for LISP objects from the BSS, and needs
  the top 4 bits of the virtual address to be clear so that
  it can encode LISP type and GC marking information there.

  But making this obscure emacs case work breaks lots of other
  stuff.  For example, programs with a reasonably large data
  section fail to load via direct ld.so interpreter execution
  because the data section is large enough to begin overlapping
  with the ELF_ET_DYN_BASE area.

  The /lib/ld-linux.so.2 emacs case does not work on a lot of
  platforms due to this issue, including i386, so it is not
  worth making work on sparc either.  It is indeed useful
  sometimes when debugging a new experimental build of glibc
  for example, but people doing that can hack the value of
  ELF_ET_DYN_BASE in their kernels.  Perhaps at some point
  we will make a sysctl controllable value.

  Signed-off-by: David S. Miller <davem@davemloft.net>

<http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/old/patch-2.6.10-rc3-bk14.log>

I don't fully understand this.  Starting programs through
/lib/ld-linux.so.2 does not appear to change the addresses at which
object files get mapped.

Do you know what the problem is and whether it is simple to fix?

For comparison, XEmacs does not have this problem.

Cheers,
Mark