Operating Systems 2026F: Tutorial 2

In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.

Getting Started

For this tutorial, you need to get access to a Linux or UNIX machine, and LinuxOnTab isn't enough. We strongly suggest you use an SCS Openstack instance (see below). You'll need access to a system for the entire semester, ideally the same one.

The concepts covered below are mostly part of standard UNIX/Linux tutorials. Feel free to consult one or more of them. However, remember that you are trying to build a conceptual model of how things work. Thus, don't memorize commands; instead, try to understand how things fit together, and ask questions when things don't work as expected!

If you find yourself searching for the answers to specific questions, you're probably doing it wrong.

Feel free to discuss this tutorial on Teams in the Tutorials channel.

Again, for emphasis: don't take snapshots! (see below)

Connecting to Openstack

SCS has lots of documentation on openstack, including a step-by-step guide. Start here!

Create a VM on the new SCS openstack cluster at openstack-stein.scs.carleton.ca and do your work there. While you don't need a persistent VM for this lab, it will be important for future tuturials - and it is nice to have your work stick around when you leave the lab.

To access Openstack you must be on the Carleton network, so make sure to VPN in if you aren't on the Carleton computer or WiFi network.

To get added to the COMP 3000 project, you need to change your SCS password (run newacct) in order to update your account to have the right entitlements.

Setting up and connecting a VM

Create a VM on the SCS openstack cluster as shown in the SCS documentation. Make sure do the following:

• Choose the COMP3000-F26.2026-* instance snapshot image ONLY (others won't have the right software for later tutorials), use the latest one.
• Add the ping-ssh-egress security group, and
• Associating a floating IP address.

The 192.168.X.X IP addresses are private (and cannot be accessed outside of the openstack cluster), the 134.117.X.X floating IP addresses can be accessed from the Carleton network and will allow you to access the wider Internet. You need to ssh to your VM instance. Windows, Ubuntu and MacOS all have SSH clients available from their command lines, just type "ssh student@<IP address>" where the IP address is the floating IP address you assigned to your VM (while connected to the Carleton VPN). Other tools supporting SSH (e.g., PuTTY) also work.

Once you are prompted to log in, the default user is student, default password is student. You'll have to change your password after you first login. (If you want to change your password later, use the passwd command.)

You can also connect directly to your instance with ssh -J (proxy), going through access:

 ssh -J <SCS username>@access.scs.carleton.ca student@<Openstack floating IP address>

(Don't use the web console unless it is an emergency, it will be glitchy. Also, x2go won't work because the VM doesn't have a desktop environment installed, on purpose.)

Backups

The image provides an "scs-backup" command that will backup the student user's directory to the SCS linux machines. So if your SCS username is janedoe, you can type:

scs-backup janedoe

and it will create a copy of everything (note: you can customize it) in the student account in a directory called "COMP3000VM-backup" in your home directory. You can ssh/sftp to access.scs.carleton.ca in order to access this copy of your VM's files.

You should do backups at the end of every session and before you do anything dangerous. While the cluster is generally stable, you should be ready for everything in it to be erased at a moment's notice, because it could happen!

Note that you cannot take snapshots of your VM, so please don't try (it will keep trying and never succeed, and you'll make work for the tech staff who have to cancel what you did).

Background

A process on UNIX-like systems are separated from each other: they run in their own address space - pointers can only refer to code and data in that program, not in other programs. Because programs are separated, they can't access anything external to them without help.

Here we're going to talk about libraries and system calls, two ways programs gain access to additional functionality. Libraries are for external code that is loaded into a process, while system calls allow for code in other processes or the OS kernel to be accessed.

You may want to refer to the background from Tutorial 1 as well.

Online Documentation (man pages)

The man (short for manual) command is one of the primary ways to to access built-in software documentation. Most software packages that provide command-line programs include man pages.

For almost any commands mentioned in the tutorials, you can use man to find the usage. While you can also find documentation online for these same commands, many have multiple variants that have different functionality. The man page is guaranteed to document the version installed on your system.

Man pages are divided into multiple sections, with each section having its own purpose, e.g., 1 for general commands, 2 for system calls, and 3 for library functions. You can specify the section as the first argument to man if there is more than one man page with the same name. For instance, tee is both a command (man 1 tee) and a system call (man 2 tee). The lowest number man page will be returned if the section is not specified.

Note that the topics in man pages go beyond just software & command manuals; they also include conventions and abstract concepts (e.g., man syscalls and man man-pages). Thus if you have questions, consider browsing the man pages rather than just going to a search engine.

Note that whatis gives you a man summary, and apropos is a quick way to search man pages.

Downloading Code & Compiling Programs

To download C programs to your VM, use wget or curl commands:

wget https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
curl https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c -o hello.c

To compile, use gcc:

gcc -O2 hello.c -o hello

This compiles it with level 2 optimization and without debugging symbols.

To run, you have to specify where it is:

./hello

Remember you can change directories using the cd command.

By default gcc-produced binaries are dynamically linked (so at runtime they will require dynamic libraries to be present on the system). To compile a binary that is statically linked (so it has no external runtime library dependencies), instead do this:

gcc -O2 -static hello.c -o hello

Assembly Language

When we write code in C, it has to be compiled to machine code before it can be run. This compilation step doesn't happen all at once. Compilation has distinct phases:

• Compile C code into assembly code (.s files).
• Assemble assembly code into machine code placed in object code files (.o files).
• Link object code files together to create a runnable binary.

If you run gcc -v, you'll see these steps all happen in a very verbose fashion.

Static & Dynamic Libraries

Most applications are not self contained; they rely on lots of external code. In compiled languages such as C, external code can be brought into the process through linking. There are two basic types of linking, static and dynamic linking:

• With static linking, code is brought in at compile time (specifically, in the link stage) and added to the executable. The code is now the same as other application code. (Static libraries are just collections of .o files.)
• With dynamic linking, a reference to the library code is added to the binary. The actual library code has to later be loaded when the program is executed. This loading will happen before main() is called.

Static and dynamic libraries are stored in /lib and /usr/lib, traditionally.

The dynamic libraries associated with a program binary can be found using the ldd command. You can use ltrace to see calls to functions that are dynamically linked. If a program is statically linked ldd will have nothing to report and will generally produce an error.

Note that code in static and dynamic libraries runs inside of the process loading the code; thus, library code has the same privileges as other application code. It can do everything regular application code can do (it can access all of your code and data), but it can do no more than your code can do (it has the same restrictions on accessing system resources).

System Calls

A process on its own has limited access to the system. It cannot directly access any external devices or data sources (e.g., files, keyboard, the screen, networks) on its own. To access these external resources, to allocate memory, or otherwise change its runtime environment, it must make system calls. Note that system calls run code outside of a process and thus cannot be called like regular function calls. The standard C library provides function wrappers for most commonly-used system calls so they can be accessed like regular C functions. Under the hood, however, these functions make use of special compiler directives in order to generate the machine code necessary to invoke system calls.

You can see the system calls produced by a process using the strace command.

In general, the code you call through a system call has more privileges than regular application code. This is because a system call is a request to the operating system kernel to do something on behalf of the process, and the kernel has full privileges to the system. (Indeed, it is the part of the system that implements the process abstraction.) We're going to talk a lot about system calls this semester, this is just your introduction to the concept.

Tasks

A: Exploring the Openstack VM

1. Join the class Team if you haven't already. Link is in brightspace.
2. How does the environment of the Openstack VM compare to the LinuxOnTab one from Tutorial 1? Specifically, how do the following compare?
1. The version of your Linux distribution and the version of your Linux kernel.
2. The name (binary path) of the current shell, and the shell version.
3. RAM, disk space, and CPU.
3. Using the man command, find out what the following commands do: which, pwd, who, whoami, env and whereis. Try using each of them.
4. Does the Openstack VM run the same or different programs for standard Linux commands? How do you know?
5. Making your own commands: the PATH environment variable lists the directories the shell uses to search for external commands. Where can you find documentation on it? How can you add the current directory (whichever directory you are currently in) to PATH? Then, how to make that change permanent? Try to identify multiple ways.
6. Compile and run csimpleshell.c. How does its functionality compare to that of bash? List at least 3 differences.

B: Function calls, library calls, and system calls

For hello.c and syscall-hello.c do the following (substituting the appropriate source file for prog.c). For example, for hello.c, you would replace all instances of "prog" in a command with "hello".

To download programs to your VM, use the wget command, e.g.

 wget https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c

1. Compile the program prog.c using gcc -O2 prog.c -o prog-dyn and run prog-dyn. What does it do?
2. Statically compile and optimize prog.c by running gcc -O2 -static prog.c -o prog-static. How does the size compare with prog?
3. Run ldd on the static and dynamic versions of the program. How does the output compare? Why?
4. See what system calls prog-static produces by running strace -o syscalls-static.log ./prog-static. Do the same for prog-dyn. Which version generates more system calls? Note: system calls are saved in the log file syscalls-static.log. Feel free to save them in a different file.
5. See what library calls prog-static produces by running ltrace -x '*' -o library-static.log ./prog-static. Do the same for prog-dyn. Which version generates more library calls? (Note: you will have to run sudo apt install ltrace to enable the command.)
6. Compile the program dynamically but with "lazy" linking: gcc -O2 -z lazy prog.c -o prog-dynlazy. Run ltrace -o library-lazy.log ./prog-dynlazy. How does the output of this compare to that of the previous ltrace?
7. (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.

C: Comparing C and assembly

Do the following with hello.c and syscall-hello.c, as before.

A few tips on x86-64 assembly language:

• The last letter of many instructions refers to the size of the operand. For example, callq means call a function using a "quad" value (64 bits).
• A dollar sign preceding a value means that it is a literal value, a percent sign means it is a register.
• If a register is in parentheses, then it is being used as a "pointer" (it contains an address, so the CPU goes to that address and interacts with the memory there). If there is a number before the parentheses, it is an offset to the register's value.

Resources on x86-64 assembly language (only needed if you want to learn more):

• CMU introduction to x86-64
• AT&T/GNU Assembler syntax
• the Wikipedia article on calling conventions

1. Using the nm command, see what symbols are defined in prog-static and prog-dyn. Which defines more symbols?
2. Run the command gcc -c -O2 prog.c to produce an object file. What file was produced? What symbols does it define?
3. Look at the assembly code of the program by running gcc -S -O2 prog.c. What file was produced? Identify the following in the assembly code (if present):
   • A function call (call)
   • A return from a function (ret)
   • Registers being saved onto the stack (push)
   • Registers being retrieved from the stack (pop)
   • Subtraction (sub)
   • A system call (syscall)
4. Disassemble the object file using objdump -d. How does this disassembly compare with the output from gcc -S?
5. Examine the headers of object file, dynamically linked executable, and the statically linked executable using objdump -h
6. Examine the contents of object file, dynamically linked executable, and the statically linked executable using objdump -s
7. Re-run all of the previous gcc commands adding the "-v" flag. What is all of that output?

D: Examining the runtime memory map

Compile and run 3000memview.c, then consider the following questions.

1. Why are the addresses inconsistent between runs? What happens if you run the program with the command "setarch -R ./3000memview"? (Note this changes how 3000memview is run.)
2. Roughly where does the stack seem to be? The heap? Code? Global variables?
3. Observe how the heap grows (i.e. the value of sbrk changes) in response to malloc calls. Would you expect the heap to ever run into the stack? Why or why not?
4. Change each malloc call to allocate more than 128K. What happens to the values of sbrk? Why? (Hint: use strace)
5. Add more code and data to the program, and add more printf's to see where things are. Are things where you expect them to be?

Code

hello.c

#include <stdio.h>

int main(int argc, char *argv[]) {

        printf("Hello world!\n");

        return 0;
}

syscall-hello.c

#include <unistd.h>
#include <sys/syscall.h>

char *buf = "Hello world!\n";

int main(int argc, char *argv) {
        size_t result;

        /* "man 2 write" to see arguments to write syscall */
        result = syscall(SYS_write, 1, buf, 13);

        return (int) result;
}

3000memview.c

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

char *gmsg = "Global Message";

const int buffer_size = 100;

int main(int argc, char *argv[], char *envp[])
{
        char *lmsg = "Local Message";
        char *buf[buffer_size];
        int i;
        
        printf("Memory report\n");
        printf("argv:      %lx\n", (unsigned long) argv);
        printf("argv[0]:   %lx\n", (unsigned long) argv[0]);
        printf("envp:      %lx\n", (unsigned long) envp);
        printf("envp[0]:   %lx\n", (unsigned long) envp[0]);

        printf("lmsg:      %lx\n", (unsigned long) lmsg);
        printf("&lmsg:     %lx\n", (unsigned long) &lmsg);
        printf("gmsg:      %lx\n", (unsigned long) gmsg);
        printf("&gmsg:     %lx\n", (unsigned long) &gmsg);

        printf("main:      %lx\n", (unsigned long) &main);

        printf("sbrk(0):   %lx\n", (unsigned long) sbrk(0));
        printf("&buf:      %lx\n", (unsigned long) &buf);

        for (i = 0; i<buffer_size; i++) {
                buf[i] = (char *) malloc(4096);
        }
        
        printf("buf[0]:    %lx\n", (unsigned long) buf[0]);
        printf("sbrk(0):   %lx\n", (unsigned long) sbrk(0));
        
        return 0;
}

csimpleshell.c

/* csimpleshell.c, Enrico Franchi © 2005
      https://web.archive.org/web/20170223203852/
      http://rik0.altervista.org/snippets/csimpleshell.html
      "BSD" license

   January 12, 2019: minor changes to eliminate most compilation warnings
   (Anil Somayaji, soma@scs.carleton.ca)
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/wait.h>
#include <sys/types.h>
#define BUFFER_SIZE 1<<16
#define ARR_SIZE 1<<16

void parse_args(char *buffer, char** args, 
                size_t args_size, size_t *nargs)
{
    char *buf_args[args_size]; /* You need C99 */
    char **cp;
    char *wbuf;
    size_t i, j;
    
    wbuf=buffer;
    buf_args[0]=buffer; 
    args[0] =buffer;
    
    for(cp=buf_args; (*cp=strsep(&wbuf, " \n\t")) != NULL ;){
        if ((*cp != NULL) && (++cp >= &buf_args[args_size]))
            break;
    }
    
    for (j=i=0; buf_args[i]!=NULL; i++){
        if(strlen(buf_args[i])>0)
            args[j++]=buf_args[i];
    }
    
    *nargs=j;
    args[j]=NULL;
}


int main(int argc, char *argv[], char *envp[]){
    char buffer[BUFFER_SIZE];
    char *args[ARR_SIZE];

    int ret_status;
    size_t nargs;
    pid_t pid;
    
    while(1){
        printf("$ ");
        fgets(buffer, BUFFER_SIZE, stdin);
        parse_args(buffer, args, ARR_SIZE, &nargs); 

        if (nargs==0) continue;
        if (!strcmp(args[0], "exit" )) exit(0);       
        pid = fork();
        if (pid){
            printf("Waiting for child (%d)\n", pid);
            pid = wait(&ret_status);
            printf("Child (%d) finished\n", pid);
        } else {
            if( execvp(args[0], args)) {
                puts(strerror(errno));
                exit(127);
            }
        }
    }    
    return 0;
}