The “state” of a computation
User view of processes – overview
recall the shared chess board analogy
processes – as viewed by the user
–
saving/restoring these positions saves/restores the game
these 32 positions constitute the “state” of the game
a game is characterized by the positions of 32 pieces
process address spaces
–
–
object modules, load modules, shared objects
–
–
registers, procedure calls, and stack frames
–
process stacks and thread stacks
–
what makes one computation different from another?
–
signals and system calls
–
what must be preserved to save/restore a computation?
–
we cannot implement computations without this list
processes – user view
we need to characterize the “state” of a computation
3/5/03 - 1
processes and process state
processes – user view
3/5/03 - 2
Processes - UNIX virtual address space
the OS implements each “computation” as a process
each process represents a “virtual” private computer
what constitutes the “state” of a "process"?
–
what makes two different games different?
–
next lecture – processes as viewed by the system
–
–
process state and virtual private computers
much of the state is hardware/CPU related:
an address space, containing code and data
a process's virtual address space is made up of
all of the memory locations that the process can
address, and looks as if the process had all of
memory for its own private use
Code segment
Data segment
hole
Stack segment
a set of address/data registers
a program counter and processor status word
–
0x00000000
but there is also a large amount of software/OS state:
additional process characteristics (e.g. priority, privileges, ...)
other resources (e.g. files and locks) each with its own state
processes – user view
3/5/03 - 3
0xFFFFFFFF
Code segment loaded near beginning of address space
Data segment starts at page boundary after code segment
Stack segment starts at high end of address space
processes – user view
3/5/03 - 4
the compilation process
(Compilation/Assembly)
source.c
compiler
Compiler
result.s
assembler
header.h
object.o
object.o
library.a
–
reads source code and header files
–
parses and understands "meaning" of source code
–
optimizer decides how to produce best possible code
–
code generation typically produces assembler code
assembler
load
module
Linkage editor
load
map
–
translates assembler directives into machine language
–
produces relocatable object modules
code, data, symbol tables, relocation information
processes – user view
3/5/03 - 5
processes – user view
3/5/03 - 6
(Relocatable Object Modules)
Typical Object Module Format
code segments
Section 1 header
section type
section length
flags
Section 2 header
section type
section length
flags
Section 3 header
section type
section length
flags
Section 4 header
section type
section length
flags
–
data segments
–
code
data
symbol
table
relocation
information
non-executable initialized data, also relocatable
symbol table
–
list of symbols defined and referenced by this module
relocation information
each code/data section is a block of information that
should be kept together in the final program
processes – user view
relocatable machine language instructions
–
3/5/03 - 7
pointers to all relocatable code and data items
processes – user view
3/5/03 - 8
Linkage Editing
Object modules, symbols, & relocation
obtain additional modules from libraries
–
Assembly code:
extern foo
Object Code:
call foo
0x108 Call instruction
0x10c 0x00000000
...
...
Library member foo.o
...
0x040 Code for foo
...
...
Symbol table:
...
...
15: foo, 0x040 global
53: foo, unresolved
...
Relocation table:
...
Relocate 0x10c by symbol 53
...
...
Symbol table:
processes – user view
3/5/03 - 9
search libraries to satisfy unresolved external references
combine all specified object modules
–
resolve cross-module references
–
copy all required modules into a single address space
–
relocate all references to point to the chosen locations
result should be complete load module
–
no unresolved external addresses
–
all data items assigned to specific virtual addresses
–
all code references relocated to assigned addresses
processes – user view
Linkage editing: resolution & relocation
Resolution
Load module
(main.o loaded at 0x4000):
0x4108 Call instruction
0x410c 0x00000000
0x4108 Call instruction
0x410c 0x00006040
(foo.o loaded at 0x6000)
(foo.o loaded at 0x6000)
0x6040
0x6040
...
...
Code for foo
...
processes – user view
Load Modules (ELF)
Relocation
Load module
(main.o loaded at 0x4000):
...
3/5/03 - 10
ELF header
version info
architecture
# load sections
# info sections
flags
...
...
...
Code for foo
...
3/5/03 - 11
processes – user view
Section 1 header
section type
load address
section length
alignment
flags
Section 2 header
section type
load address
section length
alignment
flags
Section 1 code
Section 2 data
...
3/5/03 - 12
program loading – executable code
load module (output of linkage editor)
program loading – data segments
programs include data as well as code
–
all external references have been resolved
–
all modules combined into a few segments
–
memory must be allocated for each data segment
–
includes multiple segments (text, data, BSS)
–
initial contents must be copied from load module
–
BSS: segments to be initialized to all zeroes
data too must be initialized in address space
each to be loaded in contiguous memory at a particular address
a computer cannot "execute" a load module
code is read-only, data is read/write
–
computers execute instructions in memory
–
memory must be allocated for each segment
–
code must be copied from load module to memory
processes – user view
3/5/03 - 13
Sharable executables
–
program execution can change contents of data segments
–
program can extend data segment to get more memory
processes – user view
3/5/03 - 14
address space – shared executable
code segments are usually read-only
–
one copy could be shared by multiple processes
–
allow more process to run in less memory
shared code
code has been relocated to specific addresses
–
0x00000000
private data
hole
private stack
0xFFFFFFFF
all procs must use shared code at the same
address
only the code segments are sharable
–
each process requires its own copy of writable data
–
data must be loaded into each process at start time
processes – user view
3/5/03 - 15
processes – user view
3/5/03 - 16
Shared Libraries
address space – shared libraries
normally, library modules are added to load module
–
each load module has its own copy of each library
0x00000000
this dramatically increases the size of each process
–
program must be re-linked to incorporate new library
0x01000000
shared code
private data
lib 1
existing load modules don't benefit from bug fixes
make each library a sharable code segment
–
lib 2
0x01020000 0x01030000
3/5/03 - 17
Implementing Shared Libraries
multiple code segments in a single address space
–
one for the main program, one for each shared library
–
each sharable, and mapped in at a well-known address
deferred binding of references to shared libs
applications are linkage edited against a stub library
processes – user view
3/5/03 - 18
Stub modules vs real shared libraries
stub module: libfoo.a
Symbol table:
0: libfoo.so, shared library
1: foosub1, global, absolute 0x1020000
2: foosub2, global, absolute 0x1020008
3: foosub3, global, absolute 0x1020010
4: foosub4, global, absolute 0x1020018
...
shared library: libfoo.so ... mapped at 0x1020000
0x1020000: jmp foosub1
0x1020008: jmp foosub2
0x1020010: jmp foosub3
0x1020018: jmp foosub4
...
stub module has addresses for each entry point, but no code
linkage editor resolves all references to standard map-in places
–
0xFFFFFFFF
processes automatically get the latest versions
processes – user view
–
private stack
one in memory copy, shared by all processes that need it
load them into memory when the program is loaded
–
lib 3
loader must find a copy of each referenced library
foosub1: ....
and map it in at the address where it is expected to be
foosub2: ...
processes – user view
3/5/03 - 19
processes – user view
3/5/03 - 20
Indirect binding to shared libraries
Shared Libraries vs. DLLs
both allow code sharing and run-time binding
shared libraries
Executable
Shared library
(at well known location)
Redirection Table
do not require a special linkage editor
–
references to shared objects gotten at program load time
Dynamically Loadable Libraries
Real code
Call
–
–
require much smarter linkage editor and run-time loader
–
modules are not loaded until they are needed
manually loaded by program, or automatically by run-time loader
–
complex, per-routine, initialization can be performed
e.g. allocation of private data area for persistent local variables
processes – user view
3/5/03 - 21
processes – user view
3/5/03 - 22
(run-time binding to DLLs)
Dynamic Binding to DLLs
load module includes a Procedure Linkage Table
Executable
(read-only)
Dynamically
loaded module
Call
addresses for routines in DLL resolve to entries in PLT
–
each PLT entry contains a system call to run-time loader
(asking it to load the corresponding routine)
the first time a routine is called, we call run-time loader
Run-time
loader
Procedure Linkage Table
–
which finds, loads, and initializes the desired routine
–
changes the PLT entry to be a jump to the loaded routine
–
then jumps to the newly loaded routine
subsequent calls through that PLT entry go to routine
(writeable)
processes – user view
–
3/5/03 - 23
processes – user view
3/5/03 - 24
Processes – stack frames
Process State – registers
modern programming languages are stack-based
there is more to a process than it's address space
addresses and values for ongoing computation
program counter
–
address of the next instruction to execute
–
storage for procedure local (vs global) variables
–
storage for invocation parameters
–
save and restore registers
–
processor status word
–
greatly simplified procedure storage management
each procedure call allocates a new stack frame
general registers
–
–
condition codes, execution mode, other processor state
most modern computers also have stack support
–
processes – user view
3/5/03 - 25
popped off stack when call returns
stack too must be preserved as part of process state
processes – user view
Simple procedure linkage conventions
3/5/03 - 26
Sample stack frames
called routine
calling routine
p1: parameters
push p1
; push first parameter
push p2
; push second parameter
call foo
; save PC and call subroutine
p1: saved registers
previous
stack
frame
foo:push r2-r6 ; save registers
sub =12,sp
mov rslt,r0
; return value
add =8,sp ; pop parameters
processes – user view
; restore registers
return
; restore PC
3/5/03 - 27
owned
by
caller
p2: saved registers
current
stack
frame
p2: local variables
owned
by
callee
p2: computation
add =12,sp ; pop locals
pop r2-r6
p1: computation
p2: parameters
; space for locals
...
p1: local variables
direction of growth
processes – user view
3/5/03 - 28
Process Stacks
UNIX stack space management
size of stack depends on activity of program
Code segment
–
grows larger as calls nest more deeply
–
amount of local storage allocated by each procedure
–
after calls return, their stack frames can be recycled
OS manages the process's stack segment
–
stack segment created at same time as data segment
–
some allocate fixed sized stack at program load time
–
some dynamically extend stack as program needs it
processes – user view
3/5/03 - 29
Thread state and thread stacks
each thread has its own registers, PS, PC
Data segment
hole
Stack segment
0x00000000
0xFFFFFFFF
Data segment starts at page boundary after code segment
Stack segment starts at high end of address space
Unix extends stack automatically as program needs more.
Data segment grows up; Stack segment grows down
Both grow towards the hole in the middle. They are not allowed to meet.
processes – user view
3/5/03 - 30
Thread Stack Allocation
0x00000000
each thread must have its own stack area
Code segment
maximum size specified when thread is created
Data segment
thread
1 stack
thread
2 stack
...
Process Stack segment
–
a process can contain many threads
–
they cannot all grow towards a single hole
–
thread creator must know maximum required stack size
–
stack space must be relclaimed when thread exits
0xFFFFFFFF
procedure linkage conventions remain the same
processes – user view
3/5/03 - 31
processes – user view
3/5/03 - 32
Asynchronous Exceptions and Signals
User-mode Process Signal Handlers
most program execution is synchronous
OS defines numerous types of signals
–
first execute instruction one, then execute instruction two
–
procedure calls are also completely synchronous
–
execution exceptions, operator actions, communication
user-mode programs can control their handling
calling procedure stops executing until call returns
sub-routine return value is returned to caller upon completion
not all events fit this synchronous model
–
program exceptions: zero-divide, illegal address, ...
–
external events: interrupt, hang-up, shut-down, ...
–
different programs may handle these in different ways
–
ignore this signal (pretend it never happened)
–
designate a handler for this signal
–
default action (typically kill or coredump process)
these are analogous to hardware traps
–
but delivered by software to user-mode processes
need a way to inform a program when these happen
processes – user view
3/5/03 - 33
processes – user view
Signal Handlers – sample code
3/5/03 - 34
Signals and signal handling
when an asynchronous exception occurs
int fault_expected, fault_happened;
void handler( int sig) {
–
if (!fault_expected) exit(-1); /* if not expected, die */
else fault_happened = 1; /* if expected, note it happened */
}
the system invokes a specified exception handler
invocation looks like a procedure call
–
save state of interrupted computation
signal(SIG_HUP, SIG_IGN);
/* ignore hang-up signals */
–
exception handler can do what ever is necessary
signal(SIG_SEG, &handler);
/* handle segmentation faults */
–
handler can return and resume interrupted computation
...
more complex than a procedure call and return
fault_happened = 0; fault_expected = 1;
...
/* code that might cause a segmentation fault */
fault_expected = 0;
processes – user view
3/5/03 - 35
–
must also save/restore condition codes and volatile regs
–
may not return, rather may abort current computation
processes – user view
3/5/03 - 36
System Service Requests
Stacking a signal call
synchronous (system call) model
parameters
saved registers
stack at
time of
signal
local variables
computation
standard
stack frame
for handler
application sees them as procedure calls
–
application blocks until system call completes
–
return code indicates success or failure
asynchronous (message) model
saved PC, PS and
volatile registers
hndlr parameters
–
call frame
pushed for
signal handler
hndlr saved regs
–
application calls procedure to send request (message)
–
application awaits response (in a returned message)
application may block, awaiting response message
hndlr local vars
message may be delivered as asynchronous event
...
processes – user view
exceptions may be synchronous or asynchronous
3/5/03 - 37
synchronous or asynchronous
3/5/03 - 38
why not make everything asynchronous
synchronous model is much more intuitive
synchronous model is more natural
–
processes – user view
–
people understand procedure calls
program execution is fundamentally synchronous
asynchronous computation is more powerful
asynchronous model may be more flexible
–
program continues running while awaiting response
–
it is also much more complex
–
possible to return multiple or incremental responses
–
asynchronous events must be handled by programs
–
messages can be relayed to alternate service providers
–
asynchronous processing violates sequential execution
–
asynchrony may actually be closer to reality
there are many ways to accomplish this
some requests really are processed in parallel
some requests are subject to highly variable delays
some requests are handled by another process or computer
processes – user view
3/5/03 - 39
–
signal delivery is only one approach
–
in coming weeks we will discuss many others
processes – user view
3/5/03 - 40
Key Concepts
For the next lecture
object modules, load modules
review sections 3.3, 4.6-7, read sections 6.4-7
there will be a quiz on this material
process state (context, resources, attributes)
–
supervisor mode execution
–
traps between user and supervisor mode
–
process dispatching and switching
processes – user view
contents of each, differences between, linkage editing
address space segments and program loading
–
the next lecture: processes – the system view
–
–
shared code, data, stack, shared libraries, DLLs
process context
–
saved registers, PC, PS, process and thread stacks
–
procedure calls, stack linkage conventions
synchronous and asynchronous operations
3/5/03 - 41
–
system calls, asynchronous exceptions
–
signals, signal handlers, returning from a signal
processes – user view
3/5/03 - 42