7.2 Operating System
The operating system manages resources – CPU time and Memory – and allocates them to requesting programs. Very roughly, a running program is represented by a Process within the O/S. We shall have a brief review of how an O/S manages the processes.
All the system services are accessed via System Call Interface. We shall see some examples of assembly language programs using a few common system calls.
7.2.1 A Running Program – A Process
On a Unix-like system, including Linux, many user and system processes run concurrently (are active simultaneously). The one the user has invoked usually runs in the foreground, the other processes run in the background. The command ps will show you which processes are active and what PID numbers are assigned to these processes. The command kill allows the user to get rid of any process. Without option this is a request: “please go away”, but kill –9 followed by the process PID is an immediate kill. Foreground processes can often be killed by typing Control–C.
A process is represented within the O/S kernel by a data structure called process control block (PCB), which contains all the administrative data about a process, like allocated memory areas, space for saved CPU registers, process state, etc.
The operation of the multi-tasking executive is almost completely transparent to a normal programmer and is seldom his concern. The only significant fact which emerges out of the working of the O/S, as far as a compiler writer is concerned, is the availability of the virtual memory and its protection system. In a typical O/S, for example in Linux, a flat memory of rather large size (4 Gbytes in Linux) is seen by the programmer, out of which 1 Gbyte are reserved for the Kernel use, for providing various services to the program.
If a programmer has the responsibility of developing the language library, then he will have to be familiar with other aspects of O/S.
7.2.2 Linux System Calls
On Unix, Unix-like and other POSIX-compatible operating systems, popular system calls are open, read, write, close, wait, execve, fork, exit and kill. Many of today's operating systems have hundreds of system calls. For example, Linux has over 300 different calls, and FreeBSD has almost 500.
The C library uses these System Calls for accessing various system services. For example, C library read() is just a wrapper for sys_read = 3.
Example 1: Simplest program using System Calls
Here is a very simple assembly language program, using a system call. It is in GNU assembler format.
# Text segment begins
.section .text
.globl _start
# Program entry point
_start:
# Put the code number for system call
movl $1, %eax /*
/* Return value to environment*/
movl $2, %ebx
# Call the OS
int $0x80
The above program does not have a .data segment. System Call number 1, i.e. SysCall-1, denoted by putting the value 1 in register EAX, terminates a program and returns control back to the O/S. It also returns a return code to the O/S environment by setting its value in register EBX. This value is available as value of the shell variable $? and can be read by executing the command echo $?. This little program does not do anything significant except that it returns a small integer (2) and terminates.
Note that in the GNU assembler source code format, the general form of an instruction is OP SRC, DST, which is reverse of the Intel assembly language format OP DST, SRC. Constants are prefixed by $ and register names by %. Hex constants are written starting with 0x. The operand size is indicated by a suffix to the op-code. Thus, movl denotes move long (4-bytes), movw moves 2-bytes and movb moves 1-byte.
Our second example uses three system calls – one for sys_read = 3, one for sys_write = 4 and one for sys_exit = 1. It gives a prompt for some text entry, reads it and then writes a message. The program also illustrates the use of macros to reduce the program writing effort.
Example 2: Read/Write using System Calls
.section .data
prompt_str:
.ascii ″Enter Your Name: ″
pstr_end:
.set STR_SIZE, pstr_end – prompt_str
greet_str:
.ascii ″Hello ″
gstr_end:
.set GSTR_SIZE, gstr_end – greet_str
.section .bss
// Reserve 32-bytes of memory
.lcomm buff, 32
// Macros:
// implements the write system call
.macro write str, str_size
movl $4, %eax // 4 = sys_write
movl $1, %ebx // 1 = STDOUT
movl str, %ecx
movl str_size, %edx
int $0x80
.endm
//Implements the read system call
.macro read buff, buff_size
movl $3, %eax // 3 = sys_read
movl $0, %ebx // 0 = STDIN
movl uff, %ecx movl uff_size, %edx
int $0x80
. endm
.section .text
.globl _start _
_start:
write $prompt_str, $STR_SIZE
read $buff, $32
// Read returns the length in eax
pushl %eax
// Print the hello text
write $greet_str, $GSTR_SIZE
popl %edx
// edx = length returned by read
write $buff, %edx
_exit:
movl $1, %eax
movl $0, %ebx
int $0x80
The program was assembled, linked and executed as follows:
as –o test2asm.o test2asm.S
ld –o test2asm test2asm.o
./test2asm
Enter Your Name: Pravin
Hello Pravin
The System Call Interface using the INT instruction, where the system call number was placed in the EAX register before interrupt 0x80 was executed, is a slightly dated technique. For CISC architectures such as later x86 series processors additional techniques are available. For example, we have newer interface in SYSCALL (SYSENTER), SYSRET (SYSEXIT) (the two mechanisms were independently created by AMD and Intel, respectively, but in essence do the same thing). These are fast control transfer instructions that are designed to quickly transfer control to the O/S for a system call without the overhead of an interrupt. Linux Kernel 2.5 began using this on the x86 processors.
System calls can be roughly grouped into five major categories:
- Process control,
- File management,
- Device management,
- Information maintenance,
- Communication.
Table 7.1 gives a few of the more frequently used Linux System Calls for Linux Kernel version 2.4.x.
While giving a system call the CPU registers are used to pass the arguments. The function number is put in CPU register %eax, the first argument in %ebx, …, third in %edx, fourth in %esi and fifth in %edi. In a rare case where more than five arguments are to be passed, the additional ones are pushed on the stack. Documentation of individual SysCall should be consulted to get details of the arguments to be passed.
For further information, see the Linux Kernel source directory
/usr/src/linux/include/asm–*/unistd.h,
where the wildcard * denotes the machine architecture, e.g. i386, x86_64, arm, etc.
Tracing the Linux System Calls
The system calls issued by an executable program can be traced on Linux and Unix-like systems by the utility strace(1). In the simplest case, strace runs the specified command until it exits. It intercepts and records the system calls which are called by a process and the signals which are received by a process. The name of each system call, its arguments and its return value are printed on standard error or to the file specified with the -o option.
It is a useful diagnostic, instructional and debugging tool. It is invaluable for solving problems with programs for which the source is not readily available since they do not need to be recompiled in order to trace them. Students can learn a great deal about a system and its system calls by tracing even ordinary programs.
For example, we used strace with Example 2 and obtained the following output:
$ strace ./test2asm
execve(″./test2asm″, [″./test2asm″], [/* 67 vars */]) = 0
write(1, ″Enter Your Name: ″, 17Enter Your Name: ) = 17
read(0, Pravin
″Pravin
″, 32) =7
write(1, ″Hello ″, 6Hello ) = 6
write(1, ″Pravin
″, 7Pravin
) = 7
_exit(0) = ?
Process 19744 detached
$
Note that strace waited for user input after read(0, and the user typed in Pravin.