pinkas@joker.intel.com (Israel Pinkas) (12/26/89)
About a year ago, I saw a suggestion for modifying Emacs to avoid dumping.
The suggestion (as I remember it) was that the dumped code be written out
as a C module which initialized an array. This module would then be linked
in to the final Emacs. (A dummy version of this module would be supplied
to do the initial build.)
I am currently looking into bringing Emacs up on Sys 5.4. I am running
into a number of problems that the above solution will avoid. (Not just
fix, completely avoid.) The major problems that I have hit are that the
format for binaries/object modules has changed. Sys 5.4 uses something
called ELF. (COFF modules are converted to ELF by our linkers on the fly.)
The ELF format in and of itself is not a problem, it would just require
some work to unexec.c. However, Sys 5.4 also supports dynamic libs in
addition to the shared libs of Sys 5.3.2. Unfortunately, neither shared
nor dynamic libraries are supported by Emacs at the current time.
(Somebody did send me a copy of work that he had done to get Emacs to use
SunOS 4.0 dynamic libs. I had problems that I never resolved when I tried
to build Emacs with X11. Unfortunately, I lost the message that described
the fixes.)
I believe that this would make building Emacs easier on many architectures.
It would also allow the use of dynamic and shared libraries. Last, it
would allow many systems to put the "dumped" lisp code in the shareable
text portion.
The reasoning behind the last is that many systems (almost all Unix
systems) have C compilers that generate "AT&T style" assembly code that
uses .text and .data to separate the text and data portions. For example,
for the following program:
char foo[] = {
0x00, 0x10, 0x30, 0x88, 0xff
};
my i386 compiler (Sys V.3.2) generates the following:
.file "t.c"
.version "02.01"
.data
.globl foo
foo:
.long 0x88301000
.long 0x000000ff
and my i860 compiler (Sys V.4 cross environment) generates:
.file "t.c"
.version "01.01"
.data
.globl foo
.align 1
foo:
.byte 0
.byte 16
.byte 48
.byte 136
.byte 255
.type foo,"object"
.size foo,5
By inserting a .text right before the .globl foo, the whole array would be
placed in the text portion of the executable. A simple sed script would
take care of this for 99% of all unix systems. System dependant scripts
would be very easy to write. Those system that could not do this would be
no worse off than they are now.
My first question is whether anybody has actually made this kind of change
in Emacs. If so, would you please get in contact with me.
My next question is whether any of this is already in v19? If so, would
whoever is working on it please let me know so that I don't re-invent the
wheel.
Last, could anybody point me in the right direction for implementing this
on my own. Do I just need to dump the lisp or is there anything else that
I need to worry about. I realize that this is a large undertaking, but I
am determined to bring Emacs up on my Sys 5.4 boxes. (I'll have a 486 box
and an 860 box to worry about. What makes this harder is that for the 860
we still are doing a lot of our compilation on the 486 with cross
compilation tools.
Thanks,
-Israel
--
--------------------------------------
Disclaimer: The above are my personal opinions, and in no way represent
the opinions of Intel Corporation. In no way should the above be taken
to be a statement of Intel.
UUCP: {decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!st860!pinkas
ARPA: pinkas%st860.intel.com@relay.cs.net
CSNET: pinkas@st860.intel.comjames@bigtex.cactus.org (James Van Artsdalen) (01/03/90)
In <PINKAS.89Dec25160640@joker.intel.com>, pinkas@joker.intel.com wrote: > I am currently looking into bringing Emacs up on Sys 5.4. I am doing this too. Has anyone been successful using full job control functionality and BSD signal handling? My "approach" was to configure emacs for BSD 4.3 and try to coerce it to work. I believe that this part of the port is mostly OK now. The biggest problem I am having is that SysVr4 on i386 is that the data space starts up above 0x08000000. Emacs uses the upper eight bits for flags. There are some provisions for this kind of environment (DATA_SEG_BITS?), but some places in emacs still use "if (w) { ..." without masking w. > Unfortunately, neither shared nor dynamic libraries are supported by > Emacs at the current time. I got shared libraries to work with SysVr3 a while back. It's no big deal: modify unexec() to scan the temacs binary and copy all sections to the output file, modifying the ones we want to change. Once I get a temacs that runs, I don't expect undumping to be a major undertaking, although shared libraries may take a while longer. PS. Several people sent mail recently asking for the sysVr3 shared library changes. I'm still trying to get those out. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
pcg@aber-cs.UUCP (Piercarlo Grandi) (01/05/90)
In article <25719@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes: PS. Several people sent mail recently asking for the sysVr3 shared library changes. I'm still trying to get those out. Uh? I got your changes, and they do work nice. I am going to post RSN a set of patches that include these, and patches to use BSD compatible or stream compatible ptys, etc... for V.3.2/386, so that you can have shell windows like on BSD. You just apply them to 18.54; I think that 18.55 is going to be nearly identical. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk