From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Joe Buehler Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] unexec() for Cygwin port Date: Mon, 29 Mar 2004 15:38:34 -0500 Organization: Spirent Communications, Inc. Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <4068894A.1070402@hekimian.com> References: <9003-Mon29Mar2004212726+0300-eliz@gnu.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1080592993 10060 80.91.224.253 (29 Mar 2004 20:43:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 29 Mar 2004 20:43:13 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Mar 29 22:43:08 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B83bA-0005cX-00 for ; Mon, 29 Mar 2004 22:43:08 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B83b9-0007yv-00 for ; Mon, 29 Mar 2004 22:43:07 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B83YJ-0000wX-Cx for emacs-devel@quimby.gnus.org; Mon, 29 Mar 2004 15:40:11 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B83Xq-0000rp-UB for emacs-devel@gnu.org; Mon, 29 Mar 2004 15:39:42 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B83XG-0000Sj-Nk for emacs-devel@gnu.org; Mon, 29 Mar 2004 15:39:37 -0500 Original-Received: from [64.47.34.130] (helo=minotaur.hekimian.com) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B83Wl-0000FE-8K; Mon, 29 Mar 2004 15:38:35 -0500 Original-Received: from hekimian.com (jbuehler-lt.hekimian.com [10.32.15.10]) by minotaur.hekimian.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H3A03DG7; Mon, 29 Mar 2004 15:36:00 -0500 X-Sybari-Trust: 46cebbad 61ed6794 a00fd597 0000013d User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en Original-To: Eli Zaretskii In-Reply-To: <9003-Mon29Mar2004212726+0300-eliz@gnu.org> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:21063 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21063 Eli Zaretskii wrote: >>-mallocobj = $(gmallocobj) $(rallocobj) vm-limit.o >>- >> #endif /* SYSTEM_MALLOC */ >> >> >>@@ -643,7 +645,11 @@ >> >> /* define otherobj as list of object files that make-docfile >> should not be told about. */ >>-otherobj= $(termcapobj) lastfile.o $(mallocobj) $(allocaobj) $(widgetobj) $(LIBOBJS) >>+#ifdef CYGWIN >>+otherobj= $(termcapobj) $(gmallocobj) $(rallocobj) lastfile.o vm-limit.o $(allocaobj) $(widgetobj) $(LIBOBJS) >>+#else >>+otherobj= $(termcapobj) lastfile.o $(gmallocobj) $(rallocobj) vm-limit.o $(allocaobj) $(widgetobj) $(LIBOBJS) >>+#endif > > > Can you explain the need for this change, and n particular, why is it > important to order *.o files differently for Cygwin? I believe it comes from the original xemacs code on which this was modeled. The Cygwin unexec() is a little different from typical unexec() implementations in that the dumped executable does not have segment boundaries adjusted or .data converted to .text or anything of that sort. The executable after the dump is identical to what it was at the time of unexec(). So the state of the allocators is saved by linking them before lastfile.o, which has the markers for end of emacs .data/.bss. The dumped emacs then comes up with no knowledge that it has gone through an unexec()/exec() cycle. >>+#if defined(CYGWIN) >>+ if (!bss_sbrk_did_unexec) { >>+ return bss_sbrk(increment); >>+ } >>+#endif > > > Here and elsewhere in your changes, you use code style that is > different from what we use in Emacs and in general in the GNU project: I will look for the emacs GNU indent option since they are probably documented somewhere, but if you have a pointer I would appreciate it. > Also, the code has lots of printf statements, most of which seem to be > left-overs from testing/debugging phase. If so, they should be > removed or #ifdef'ed away, I think. Some of them are for error cases, which I definitely don't want to change. All of them only apply to undumping, which only happens during a build. I would like them to stay to help in solving any reported problems. > Btw, does unexcw.c handle correctly the debug info in temacs.exe, > i.e., is that info copied into emacs.exe so that Emacs could be > debugged? (I'm asking because I don't see code that copies and > possibly fixes up the debug info sections.) It should. All unexec() does for Cygwin is convert .bss into an initialized data segment by changing some flags in the section header and appending the data to the .exe file. And rewrite the appropriate part of .data, of course. -- Joe Buehler