From owner-FreeBSD-tech-jp@jp.freebsd.org  Fri Dec 12 10:02:42 1997
Received: by jaz.jp.freebsd.org (8.8.8+3.0Wbeta7/8.7.3) id KAA03115
	Fri, 12 Dec 1997 10:02:42 +0900 (JST)
Received: by jaz.jp.freebsd.org (8.8.8+3.0Wbeta7/8.7.3) with ESMTP id KAA03109
	for <FreeBSD-tech-jp@jp.freebsd.org>; Fri, 12 Dec 1997 10:02:39 +0900 (JST)
Received: (from asami@localhost) by vader.cs.berkeley.edu (8.8.7/8.7.3) id RAA15363; Thu, 11 Dec 1997 17:02:37 -0800 (PST)
Date: Thu, 11 Dec 1997 17:02:37 -0800 (PST)
Message-Id: <199712120102.RAA15363@vader.cs.berkeley.edu>
To: FreeBSD-tech-jp@jp.freebsd.org
In-reply-to: <199712111407.XAA06270@eddie.snipe.rim.or.jp> (message from Motoyuki Konno on Thu, 11 Dec 1997 23:07:58 +0900)
From: asami@cs.berkeley.edu (Satoshi Asami)
Reply-To: FreeBSD-tech-jp@jp.freebsd.org
Precedence: bulk
X-Distribute: distribute [version 2.1 (Alpha) patchlevel=24]
X-Sequence: FreeBSD-tech-jp 1000
Subject: [FreeBSD-tech-jp 1000] Re: Emacs and unexec in 3.0-CURRENT
Errors-To: owner-FreeBSD-tech-jp@jp.freebsd.org
Sender: owner-FreeBSD-tech-jp@jp.freebsd.org

 *   $B:#Ln$G$9!#(B

 *   hackers ML $B$G$O!V(B-current $B$G:n$jD>$7$F$M!W$GOC$,$H$j$"$($:=*(B
 * $B$o$C$F$7$^$C$?$h$&$G$9$,!"$$$m$$$m%A%'%C%/$7$J$1$l$P$J$i$J$$$h(B
 * $B$&$G$9!#(B

$B;d$N5-21$,3N$+$J$i$P!J$3$l$,$"$^$j$"$F$K$J$i$J$$$N$G$9$,(B...^_^;$B!K!":G(B
$B?7$N(B -current$B$G$O$$$D:n$C$?(B emacs$B$G$b;H$($k$h$&$K%O%C%/$5$l$F$$$?$H;W(B
$B$&$N$G$9$,!#(B

$B$G$b!"$3$l$O%@%s%W$9$k;~$NLdBj$G$O$J$$$G$9$M!#!J%@%s%W$7$?8e$N<B9T7A<0(B
$B$,;H$($k$+$I$&$+$NLdBj!#!K$8$c!"0c$&$N$+$J!)(B

$B$"$5$_(B

$B;29M(B:
-----
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
cc: current@freebsd.org
Subject: Re: Heads up: recent ld.so changes broke emacs 
Date: Thu, 04 Dec 1997 19:58:33 -0800
From: John Polstra <jdp@polstra.com>

> Emacs may think that it has a monopoly on calling sbrk() that would
> be bad :-(

Luckily, that's not it.  The problem, essentially, is that the emacs
executable is invalid.

When emacs is built, first the Makefile builds a virgin version named
"temacs" using normal cc commands.  Then it runs temacs in batch
mode, telling it to load all the common built-in lisp modules.  After
loading them into memory, temacs then "unexec"s itself.  What does
that mean?  It copies its address space out to a file, and fakes up an
a.out header at the beginning of it so that the file can be executed
directly.  That file becomes the emacs that is installed.

Unfortunately, the file isn't quite a valid executable.  The special
symbols "_edata" and "_end", which would normally be be be generated
by the linker, have incorrect values.

The dynamic linker was using the value of "_end" to set the initial
break level that sbrk uses.  Since the value was wrong, the memory
allocations were trampling on emacs data, thereby causing it to
coredump.

To work around the bug, I changed the dynamic linker to calculate its
break level based on the segment sizes in the a.out header.  Luckily,
it can access the header, because under FreeBSD the a.out header is
mapped into memory near the beginning of the program's address space.

Xemacs has a better unexec package, which sets the values of the
special symbols correctly.  That's why it worked but GNU emacs didn't.

I committed the workaround this evening, and everything should
function fine again.

John
--
   John Polstra                                       jdp@polstra.com
   John D. Polstra & Co., Inc.                Seattle, Washington USA
   "Self-knowledge is always bad news."                 -- John Barth
