From owner-freebsd-current  Mon Mar 31 19:29:51 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id TAA04069
          for current-outgoing; Mon, 31 Mar 1997 19:29:51 -0800 (PST)
Received: from austin.polstra.com (austin.polstra.com [206.213.73.10])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA04064
          for <current@freebsd.org>; Mon, 31 Mar 1997 19:29:46 -0800 (PST)
Received: from austin.polstra.com (jdp@localhost)
	by austin.polstra.com (8.8.5/8.8.5) with ESMTP id TAA25551;
	Mon, 31 Mar 1997 19:28:52 -0800 (PST)
Message-Id: <199704010328.TAA25551@austin.polstra.com>
To: terry@lambert.org
Subject: Re: A new Kernel Module System
Newsgroups: polstra.freebsd.current
In-Reply-To: <199703312059.NAA10110@phaeton.artisoft.com>
References: <199703312059.NAA10110@phaeton.artisoft.com>
Organization: Polstra & Co., Seattle, WA
Cc: current@freebsd.org
Date: Mon, 31 Mar 1997 19:28:52 -0800
From: John Polstra <jdp@polstra.com>
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In article <199703312059.NAA10110@phaeton.artisoft.com>,
Terry Lambert  <terry@lambert.org> wrote:
> I've felt for a long time now that the intent of the memory hole
> at the start of the executable in the ELF SVR4 EABI was to allow
> the mapping of the ld.so into the process address space without
> there being code in crt0.o to actually do the work.

That is exactly the case in SVR4.  The kernel maps the combined libc+ld.so
into the hole before execution begins.
--
   John Polstra                                       jdp@polstra.com
   John D. Polstra & Co., Inc.                Seattle, Washington USA
   "Self-knowledge is always bad news."                 -- John Barth