a stupid question

[HEDRICK at RUTGERS.ARPA]

From:  Charles Hedrick <HEDRICK at 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!
  
-------