rpw3@redwood.UUCP (Rob Warnock) (01/01/85)
Andrew Klossner <andrew@orca.UUCP> writes: +--------------- | CMS is a single-user IBM 370 operating system. When it runs | stand-alone on a 370, it supports a single user. Several instances of | it can be running under CP, each in a distinct virtual machine... | | There is some user interface in CP, but not much ... it's mostly of the | "simulate a front panel" variety, like the command to boot an operating | system in your virtual machine. +--------------- I find it interesting to compare TOPS-10, which was originally (in the PDP-10/30 configuration) a single user monitor. When it became a timesharing system, the user view of a single-user system persisted. Your "job" was a virtual machine, albeit with system calls in the "hardware" (much like the later versions of CP with the extended "diagnose" call). You managed your "core image" via front-panel-like commands, such as "examine" and "deposit". It was perfectly legal to sit and type octal machine code into (your job's) core and run it. You could "get" an image, run it, halt it, patch it, and "save" it again. When a program exited, the core image was still there. In fact, certain large programs depended on this -- after compiling one of them you would run it one time so it could build its symbol tables (or whatever), then it changed its starting address and exited so you could save it with the startup code already done (a trick "ps" could use, no doubt!). Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404
rcd@opus.UUCP (Dick Dunn) (01/08/85)
> ... > You managed your "core image" via front-panel-like commands, such as "examine" > and "deposit". It was perfectly legal to sit and type octal machine code into > (your job's) core and run it. You could "get" an image, run it, halt it, patch > it, and "save" it again. When a program exited, the core image was still there. > > In fact, certain large programs depended on this -- after compiling one > of them you would run it one time so it could build its symbol tables (or > whatever), then it changed its starting address and exited so you could save > it with the startup code already done (a trick "ps" could use, no doubt!). This is a trick I've seen in more than one interpretive implementation of a language. A predefined procedure is provided in the language which "freezes" a copy of the program, interpreter and all, at the point the procedure is called. When you have a program which requires a lot of setup (or if the interpreter itself has a long startup time), you "freeze" the program after the initialization and save the image at that point for people to use. It could conceivably even be useful for compiled implementations of languages such as Pascal which (in their standard form) lack data initialization. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...I'm not cynical - just experienced.
BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa> (01/10/85)
> In fact, certain large programs depended on this -- after compiling one > of them you would run it one time so it could build its symbol tables (or > whatever), then it changed its starting address and exited so you could save > it with the startup code already done (a trick "ps" could use, no doubt!). We were distributed with our laser printer software a UNIX (4.2 dependent probably) program called 'undump.c' What it seems to do quite reliably is take a 'core' and turn it back into an a.out which will start up as it was at the time of the core dump (eg. after a SIGQUIT.) I tried it on our EMACS and it almost works. EMACS certainly starts up in the state it was dumped (EMACS goes through a long, complicated and very necessary init phase.) The obvious problem (here's the rub!) is that it won't re-read the command line (argc,argv). OBVIOUSLY! Oh well, TOPS-20 always had this feature but programs often need to be written to sense that they have been re-started so they at least do a little re-init, like re-reading the command line. The only programs that could likely work as is are those that immediately sit in a read-eval loop at the terminal rather than reading the command line (LISP comes to mind.) [ok, not that LISP doesn't read the cmd line, just that you could immediately after re-starting do whatever might have been done via the command line. Editors generally have this property (Visit File or :e or whatever.(] -Barry Shein, Boston University P.S. undump.c may very well have come off of some public domain source. If anyone knows I would be glad to re-distribute. If you just ask me for it I'll try to check into it myself, maybe there's a comment somewhere.
thomas@utah-gr.UUCP (Spencer W. Thomas) (01/10/85)
In article <7152@brl-tgr.ARPA> BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa> writes: > We were distributed with our laser printer software a > UNIX (4.2 dependent probably) program called 'undump.c' > What it seems to do quite reliably is take a 'core' > and turn it back into an a.out which will start up as > it was at the time of the core dump (eg. after a SIGQUIT.) > > I tried it on our EMACS and it almost works. EMACS certainly > starts up in the state it was dumped (EMACS goes through > a long, complicated and very necessary init phase.) The > obvious problem (here's the rub!) is that it won't re-read > the command line (argc,argv). Mea culpa! I wrote undump a long time ago to help out the local lisp folks. Then I wrote a subroutine called unexec which takes a snapshot of a running program. Undump was originally written on 4.1, but was ported to V7, at least (and probably others). Unexec() is more OS dependent, but has been ported to some other Unix versions (I think - I've pretty much lost track of its evolution at this point). Back when (Gosling) Emacs didn't have compiled mlisp, I converted our emacs to use unexec. I had to add "if (!Once){...}" to all the one-time initialization code, but it worked fine after that. I don't understand the problem with not reading argc, argv again, unless the undump you got is fancier than mine - I didn't save pc or stack, so you always re-entered the program through main. If yours saves full state, I might be interested to see it. In any case, if there is enough interest (time to get a bigger mailbox), I can post both again (I did it once, but that was years ago). (But I can't post the emacs mods - they're long lost.) -- =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA) <<< Silly quote of the week >>>
Bob Walsh <walsh@bbn-labs-b> (01/10/85)
It is simple to write a program that will take a core image and produce an executable. You can also write a subroutine to do the same thing. I tried to do it for Scheme-in-T at Harvard, and one problem we ran into was that open file descriptors are lost. bob walsh
jack@vu44.UUCP (Jack Jansen) (01/10/85)
> From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa> > We were distributed with our laser printer software a > UNIX (4.2 dependent probably) program called 'undump.c' > What it seems to do quite reliably is take a 'core' > and turn it back into an a.out which will start up as > it was at the time of the core dump (eg. after a SIGQUIT.) This sounds interesting. I wrote such a routine some time ago for a CDC Cyber, and it was *very* useful. I was thinking about writing something like it for unix, but the problem seems to be the stack. I couldn't figure a way to initialize the stack from a core image. Anyone has any ideas how to perform that feat? -- Jack Jansen, {seismo|philabs|decvax}!mcvax!vu44!jack or ...!vu44!htsa!jack If *this* is my opinion, I wasn't sober at the time.