[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] unexec() for Cygwin port

From: Joe Buehler
Subject: Re: [PATCH] unexec() for Cygwin port
Date: Mon, 29 Mar 2004 15:38:34 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316

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) 
+#ifdef CYGWIN
+otherobj= $(termcapobj) $(gmallocobj) $(rallocobj) lastfile.o vm-limit.o 
$(allocaobj) $(widgetobj) $(LIBOBJS)
+otherobj= $(termcapobj) lastfile.o $(gmallocobj) $(rallocobj) vm-limit.o 
$(allocaobj) $(widgetobj) $(LIBOBJS)

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);
+  }

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]