HEDRICK@RUTGERS.ARPA@sri-unix.UUCP (07/20/84)
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA> This is going to sound stupid, but the one thing I haven't yet figured out about Unix is what programs look like in memory and how they get there. I have figured out that there are two "segments", for code and data. But it is not obvious to me where they are in the address space and how they get there. It is also not obvious if you want to get more space, what the constraints are. In particular, can I just refer to a random location, or do I have to create the page first? Can I create random discontiguous pages, or is it like the old Tops-10 system, where I do an "expand core" call, which allocates everything up to the address I specify? (I am sending this message to INFO-PYRAMID as well as INFO-UNIX because there is some reason to think that there may be some information here that is specific to the Pyramid.) Finally, is there anything like the Tops-20 "I MEM" command? This shows you all of the pages in your core image. More precisely, it is an EXEC (i.e. shell) command that looks at the currently selected fork (i.e. "job", in csh terms) and says what pages in it exist, and their attributes (readable, writable, executable, mapped to a page in another process, mapped to a file) In general, let me say that I feel sort of deaf, blind, and dumb on Unix. I am used to the following commands on Tops-20. I would love to hear about their equivalent on Unix. Some of them probably belong in the debugger. However it turns out to be convenient to be able to look around in this way when something goes wrong and you don't happen to have the debugger loaded. (The EXEC even has a built-in disassembler for use in the EXAMINE command. I would be just as happy if SDB had these features, and could be called in on an active core image without affecting it.) ^T - you can type this at any time - it gives a summary of what is going on. It gives roughly the information shown by the JOBS and TIME commands in the CSH. It is also a great pacifier when the system is heavily loaded. The EXEC (shell) simply arms ^T as an interrupt character. If a user program wants to set up its own ^T trap, then it will get the interrupt itself. This allows Lisp to tell you what function it is currently executing, FTP to tell you how far it has gotten in the transfer, etc. SET ADDRESS-BREAK nnn, break-type - uses the hardware address break. Whenever the specified address is accessed (you can specify read, write, execute), stop the program. This is the single most useful debugging tool I know. Without it I don't see any way I would have found certain subtle garbage collection bugs. Because the address break is supported in the hardware (it is an attribute of the process table), it does not slow down the program as it would if the debugger had to single-step the program and check the location after each instruction. A reasonable facimile could be fashioned from the ability to write illegal parity into a specified word. INFO FILE-STATUS - show all open jfn's (fd's), what file they are open on and the current byte position INFO FORK-STATUS - Gives data similar to ^T, but for all processes (jobs) under the current EXEC (shell). INFO MEMORY - show memory structure of currently selected process INFO PSI - for currently selected process, shows what interrupts are enabled, what are pending, and locations of various interrupt vectors. INFO VERSION - for currently selected process, shows certain identifying information which is built into the module at compile-time. It used to be that this was a single version number, for the whole program, but now each module has its own "program data vector", from which this gives the module name and version number. DDT - load the debugger on the current process. We don't do core dumps. Instead we load DDT and look around. Sometimes we can continue and see what happens. That is very hard to do with a dump! -------
rehmi@MARYLAND.ARPA (07/20/84)
From: Rehmi <rehmi@MARYLAND.ARPA> I've got a real nice little ^T for 4.1 which I'm going to put into 4.2 soon. Anyone want one? ~r_
geoff@utcsstat.UUCP (Geoff Collyer) (07/24/84)
--- From: Mark Weiser <mark@MARYLAND.ARPA> INFO FILE-STATUS - show all open jfn's (fd's), what file they are open on and the current byte position Not a standard command, but not that hard to write. Looks like a good idea. --- pstat -f output gives a somewhat cryptic form of what is wanted; combined with output of pstat -i and ncheck -i (which I grant is slow), one could put together what is really wanted.
mark@MARYLAND.ARPA@sri-unix.UUCP (07/26/84)
From: Mark Weiser <mark@MARYLAND.ARPA> ... is it like the old Tops-10 system, where I do an "expand core" call, which allocates everything up to the address I specify? yes. sbrk(). ^T - yes. We have a nice version of this at Maryland running on our Vax Unix, which has user settalbe options for customizing what YOU would like to see at ^T time. Watch for a pyramid version soon on this list. SET ADDRESS-BREAK nnn, break-type - no. INFO FILE-STATUS - show all open jfn's (fd's), what file they are open on and the current byte position Not a standard command, but not that hard to write. Looks like a good idea. INFO FORK-STATUS - Gives data similar to ^T, but for all processes (jobs) under the current EXEC (shell). ps u INFO MEMORY - show memory structure of currently selected process no. INFO PSI - for currently selected process, shows what interrupts are enabled, what are pending, and locations of various interrupt vectors. no. INFO VERSION - for currently selected process, shows certain identifying information which is built into the module at compile-time. It used to be that this was a single version number, for the whole program, but now each module has its own "program data vector", from which this gives the module name and version number. Yes. Unix has two verison control systems, SCCS and RCS. Both supply this feature.
darryl@ism780.UUCP (08/01/84)
#R:sri-arpa:-19000:ism780:20700001:000:600
ism780!darryl Jul 24 07:37:00 1984
The old CP-V system on the {S,X}DS Sigma machines had a similar feature.
When you typed a ^D (or some such, I don't recall specifically), it
responded with the current state your program (1 process per user, you
know) was in. It also had another effect, though: if you were in one
of the many different possible waiting states, this query moved you to the
head of the list. Many people used pens to hold the control and D keys
down while they ran a program! Have you played the "Track and Field" video
game yet? CP-Vers have been for years!
--Darryl Richman
...!cca!ima!ism780!darryl