weikart@arisia.Xerox.COM (Scott Weikart) (11/13/88)
I'm using GNU Emacs 18.52 on a 386/AT clone, with MicroPort Unix and Everex's Enix (both derived from AT&T V/386, System 5 Release 3.0). Has anyone been able to successfully dump a GNU Emacs with the read-only data region remapped into the text region, i.e. with #undef NO_REMAP ? I got the following comment on this: > I do not know the answer. The problem is that the data space starts > well away from the text space. Supposedly ld -N can move them closer, > but that appears to be broken: it doesn't work for any program I've > tried, much less GNU emacs. I suggest posting to gnu.emacs and seeing > if anyone has found a way. Let me know if you find one. Good Luck! > --- > James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" > Home: 512-346-2444 Work: 338-8789 9505 Arboretum Blvd Austin TX 78759 Does anyone know if ld -N works in Release 3.1 or 3.2 of V/386? Also, it has been suggested that #undef NO_REMAP isn't as important with System V release 3, because under Vr3 a new exec shares an existing data region, and uses copy on write to replace the data region pages that get changed, so that in general there is only one copy of the Emacs libraries in memory even if there are multiple Emacses running. Is this correct? -scott -- weikart@arisia.xerox.com pyramid!cdp!scott (415)322-9069
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (11/15/88)
weikart@arisia.Xerox.COM (Scott Weikart) writes: > I do not know the answer. The problem is that the data space starts > well away from the text space. Supposedly ld -N can move them closer, > but that appears to be broken: it doesn't work for any program I've > tried, much less GNU emacs. I suggest posting to gnu.emacs and seeing > if anyone has found a way. Let me know if you find one. Good Luck! Does anyone know if ld -N works in Release 3.1 or 3.2 of V/386? Also, it has been suggested that #undef NO_REMAP isn't as important with System V release 3, because under Vr3 a new exec shares an existing data region, and uses copy on write to replace the data region pages that get changed, so that in general there is only one copy of the Emacs libraries in memory even if there are multiple Emacses running. Is this correct? Writing as the person who did the first port to real, original, AT&T VAX-11/780 SysVRel5.0 (borrowing heavily from the work of others who ported it to semi-SysV things like Duals and Strides) under GNU Emacs 16.54 about 3 years ago... You do ***NOT*** want to use ld -N. The `feature' which -N provides for you is to make the text and data segments of the resulting binary into ONE SEGMENT, which is to say, it is not write-locked and shared among the N possible incarnations of the binary. This means Bad Things for how hard your system will swap when the 2nd incarnation of it starts up. Just because you might be on a little PC-sized 386 thing isn't sufficient justification - sometime you'll have a window with one sitting there while kicking off an editor in another under your mailer, and then your system will start to choke and die. I was using a 4Mb 780 which choked quite badly enough; I'd hate to think what your disc seek time will do to you. So, yes, ld -N puts text & data closer together...by making them the same thing, and the one just runs straight into the other. Do you really want to chase down a bad-pointer bug, when you have scribbled over code with that bad pointer, and so now mysteriously fails at random times? SysVRel2 & higher want to separate text & data by fairly large amounts of empty address space; it is in your best interest to leave them separated and put up with the fixed lisp code being in data space. This is to say that your comment at the end about the sharing of spaces is correct anyway; that VM, when done properly, doesn't mess with copying things, even in writable data space, until someone actually performs a write to make their data space different from yours. --Karl
jr@bbn.com (John Robinson) (11/15/88)
In article <442@arisia.Xerox.COM>, weikart@arisia (Scott Weikart) writes: >Also, it has been suggested that #undef NO_REMAP isn't as important with >System V release 3, because under Vr3 a new exec shares an existing data >region, and uses copy on write to replace the data region pages that get >changed, so that in general there is only one copy of the Emacs libraries in >memory even if there are multiple Emacses running. Is this correct? For this to be true, you still need to load (as in "ld") the libraries into data space. So the only difference to do this compared to existing undump code is whether the pure lisp gets stuffed into text or data. Putting it into data will allow some machines to execute dumped emacs that couldn't before due to mapping restrictions. Better on machines with shared libraries would be to cons all the emacs .elc files into a shared library, to which emacs links on startup. Anyone working on this approach? Is it hopeless, given the rate with which changes to the library components appear? -- /jr jr@bbn.com or bbn!jr
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (11/15/88)
karl@triceratops.cis.ohio-state.edu (that's me) bumbled: VAX-11/780 SysVRel5.0 Sheesh. Every now and then, a stray beta particle takes out a synaptic gap somewhere north of the visual cortex in my brain. That should have been something more along the lines of "SysV.0" or "USG 5.0," or perhaps "UNIX Release 5.0," or something other than what I wrote. They hadn't gotten around to noting SysVRelease <x> when I was messing about with porting to that system...
dougm@ico.ISC.COM (Doug McCallum) (11/17/88)
In article <442@arisia.Xerox.COM> weikart@arisia.Xerox.COM (Scott Weikart) writes: ... >I'm using GNU Emacs 18.52 on a 386/AT clone, with MicroPort Unix and Everex's >Enix (both derived from AT&T V/386, System 5 Release 3.0). Has anyone been >able to successfully dump a GNU Emacs with the read-only data region remapped >into the text region, i.e. with #undef NO_REMAP ? I got the following comment >on this: ... >Also, it has been suggested that #undef NO_REMAP isn't as important with >System V release 3, because under Vr3 a new exec shares an existing data >region, and uses copy on write to replace the data region pages that get >changed, so that in general there is only one copy of the Emacs libraries in >memory even if there are multiple Emacses running. Is this correct? On a standard V.3 paging system the the data segment is copy-on-write and it should be that way on the 386 system you have, it is on mine. Also, 386 memory regions are at 4 megabyte boundaries. That is, data in emacs starts at 4 meg so trying to push it into text would require some creative use of the load file option of ld. The amount of extra work wasn't worth it when I first did 386 support in GNU so I didn't do it and apparently no one has since. Hope this helps, Doug McCallum dougm@ico.isc.com