Vserbu: Pagină nouă: In the last lab, we saw how a user-space program asks the kernel for services through '''system calls''', and what the kernel places...

2026-10-23T07:26:45Z

Pagină nouă: In the last lab, we saw how a user-space program asks the kernel for services through '''system calls''', and what the kernel places...

Pagină nouă

In [[OS_Lab_2_-_System_calls._The_initial_stack|the last lab]], we saw how a user-space program asks the kernel for services through '''system calls''', and what the kernel places on the stack before <code>main()</code> runs. In this lab, we will use system calls to work with '''files''': open them, map them into memory, read and write them, and list the contents of directories. As an application, we will look inside the executable file of our own program.

== Learning objectives ==

By the end of this lab you should be able to:

# explain what a file descriptor is, and open and close files with [https://man7.org/linux/man-pages/man2/open.2.html <code>open(2)</code>] and [https://man7.org/linux/man-pages/man2/close.2.html <code>close(2)</code>];
# map a file into memory with [https://man7.org/linux/man-pages/man2/mmap.2.html <code>mmap(2)</code>], and allocate memory with anonymous mappings;
# read and write files with [https://man7.org/linux/man-pages/man2/read.2.html <code>read(2)</code>] and [https://man7.org/linux/man-pages/man2/write.2.html <code>write(2)</code>], and move the file offset with [https://man7.org/linux/man-pages/man2/lseek.2.html <code>lseek(2)</code>];
# list the entries of a directory with [https://man7.org/linux/man-pages/man3/readdir.3.html <code>readdir(3)</code>] and relate them to inode numbers;
# describe the layout of an ELF executable and find a program header, such as <code>PT_INTERP</code>, in it.

== System call wrappers ==

In the last lab, we called every system call through the generic [https://man7.org/linux/man-pages/man2/syscall.2.html <code>syscall(2)</code>] function, to see the system call numbers at work. In practice, this is very rarely done: for each system call, the GNU C library (''glibc'') provides a small C function with the same name and the same arguments, which only calls the syscall function with the appropriate number.

{| class="wikitable"
! System call !! glibc wrapper
|-
| <code>syscall(SYS_write, fd, buf, count)</code> || <code>write(fd, buf, count)</code>
|-
| <code>syscall(SYS_read, fd, buf, count)</code> || <code>read(fd, buf, count)</code>
|-
| <code>syscall(SYS_close, fd)</code> || <code>close(fd)</code>
|-
| <code>syscall(SYS_mmap, addr, length, prot, flags, fd, offset)</code> || <code>mmap(addr, length, prot, flags, fd, offset)</code>
|}

The wrappers handle errors in the same way as [https://man7.org/linux/man-pages/man2/syscall.2.html <code>syscall(2)</code>]: on failure they return <code>-1</code> (or another special value, as we will see for [https://man7.org/linux/man-pages/man2/mmap.2.html <code>mmap(2)</code>]) and set <code>errno</code>. From now on, we will use the wrappers.

<div class="regula">'''Note:''' Not every function in glibc is a thin wrapper. [https://man7.org/linux/man-pages/man3/printf.3.html <code>printf(3)</code>], [https://man7.org/linux/man-pages/man3/puts.3.html <code>puts(3)</code>] and [https://man7.org/linux/man-pages/man3/fopen.3.html <code>fopen(3)</code>] belong to the C standard I/O library (''stdio''), which keeps its own buffers in user space and calls [https://man7.org/linux/man-pages/man2/write.2.html <code>write(2)</code>] and [https://man7.org/linux/man-pages/man2/read.2.html <code>read(2)</code>] only from time to time. In the labs, we will aim to talk to the kernel directly, and will use only the thin wrappers.</div>

== Files ==

A '''file''' is an array of bytes, identified by an '''inode''', and found by a name in a '''directory'''. The same system calls are used for regular files, for devices (such as the terminal) and for other kinds of files, which we will meet in future lessons.

=== open(2) and close(2) ===

A program cannot use a file by its name directly. It first asks the kernel to '''open''' it:

<syntaxhighlight lang="c">
// In: <fcntl.h>
int open(const char *pathname, int flags, ... /* mode_t mode */);
</syntaxhighlight>

The kernel finds the file, checks the permissions, and records the open file in a table of the process. It returns a small integer, the '''file descriptor''', which identifies the open file in all the following system calls. When the program is done with it, it releases the file descriptor with:

<syntaxhighlight lang="c">
// In: <unistd.h>
int close(int fd);
</syntaxhighlight>

Every process starts with three file descriptors already open, inherited from the program that started it (usually the shell):

{| class="wikitable"
! File descriptor !! Constant !! Name
|-
| 0 || <code>STDIN_FILENO</code> || Standard input
|-
| 1 || <code>STDOUT_FILENO</code> || Standard output
|-
| 2 || <code>STDERR_FILENO</code> || Standard error
|}

[[File:OS_Lab_3_-_fd_table.png|center|thumb|700px|Each process has a table of file descriptors. Each entry points to an open file in the kernel, which records the current offset and the access mode, and points to the file itself.]]

The <code>flags</code> argument must contain exactly one of the access modes <code>O_RDONLY</code>, <code>O_WRONLY</code> or <code>O_RDWR</code>, optionally combined (with <code>|</code>) with other flags:

{| class="wikitable"
! Flag !! Description
|-
| <code>O_RDONLY</code> || Open for reading only
|-
| <code>O_WRONLY</code> || Open for writing only
|-
| <code>O_RDWR</code> || Open for reading and writing
|-
| <code>O_CREAT</code> || Create the file if it does not exist. Requires the third argument, <code>mode</code>, with the permissions of the new file (for example <code>0644</code>)
|-
| <code>O_EXCL</code> || Together with <code>O_CREAT</code>: fail with <code>EEXIST</code> if the file already exists
|-
| <code>O_TRUNC</code> || If the file exists, cut its size to 0
|-
| <code>O_APPEND</code> || Every write goes to the end of the file
|}

For example, the shell runs <code>echo hi > notes.txt</code> by opening the file with <code>open("notes.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644)</code>, and <code>echo hi >> notes.txt</code> with <code>O_APPEND</code> instead of <code>O_TRUNC</code>.

<syntaxhighlight lang="c" line>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

static void print_error(const char *what)
{
char msg[256];
snprintf(msg, sizeof msg, "%s: %s\n", what, strerror(errno));
write(STDERR_FILENO, msg, strlen(msg));
}

int main(int argc, char **argv)
{
if (argc != 2) {
const char usage[] = "Usage: app FILE\n";
write(STDERR_FILENO, usage, strlen(usage));
return EXIT_FAILURE;
}

int fd = open(argv[1], O_RDONLY);
if (fd == -1) {
print_error(argv[1]);
return EXIT_FAILURE;
}

char msg[256];
snprintf(msg, sizeof msg, "Opened %s as file descriptor %d\n", argv[1], fd);
write(STDOUT_FILENO, msg, strlen(msg));

close(fd);
return EXIT_SUCCESS;
}
</syntaxhighlight>

<syntaxhighlight lang="bash">
$ ./build/debug/app notes.txt
Opened notes.txt as file descriptor 3
$ ./build/debug/app nope
nope: No such file or directory
</syntaxhighlight>

=== mmap(2) ===

There are two ways for a program to get to the data in a file. The first is the '''transparent''' one: the kernel makes the file appear in the virtual memory of the process, and the program uses it like any other memory. This is done with [https://man7.org/linux/man-pages/man2/mmap.2.html <code>mmap(2)</code>]:

<syntaxhighlight lang="c">
// In: <sys/mman.h>
void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);
int munmap(void *addr, size_t length);
</syntaxhighlight>

{| class="wikitable"
! Parameter !! Description
|-
| <code>addr</code> || A hint for where to place the mapping. Use <code>nullptr</code>, and let the kernel choose
|-
| <code>length</code> || The number of bytes to map. The kernel maps whole pages, so it is rounded up to a multiple of the page size
|-
| <code>prot</code> || What the program may do with the memory: <code>PROT_READ</code>, <code>PROT_WRITE</code>, <code>PROT_EXEC</code>, combined with <code>|</code>, or <code>PROT_NONE</code>
|-
| <code>flags</code> || <code>MAP_PRIVATE</code>: writes to the memory stay in this process and never reach the file. <code>MAP_SHARED</code>: writes go to the file, and other processes mapping it see them
|-
| <code>fd</code> || The open file to map. It must have been opened for reading
|-
| <code>offset</code> || Where in the file the mapping starts. Must be a multiple of the page size
|}

On success, [https://man7.org/linux/man-pages/man2/mmap.2.html <code>mmap(2)</code>] returns the address of the first mapped byte. On failure, it returns <code>MAP_FAILED</code> (which is <code>(void *) -1</code>, '''not''' <code>nullptr</code>) and sets <code>errno</code>.

[[File:OS_Lab_3_-_mmap_file.png|center|thumb|650px|[https://man7.org/linux/man-pages/man2/mmap.2.html <code>mmap(2)</code>] makes the file appear in virtual memory: <code>p[i]</code> is the byte at offset <code>i</code> in the file. The pages are read from the disk only when the program first touches them.]]

To map the whole file, we need to know its size. We will look at [https://man7.org/linux/man-pages/man2/lseek.2.html <code>lseek(2)</code>] in detail below, together with [https://man7.org/linux/man-pages/man2/read.2.html <code>read(2)</code>] and [https://man7.org/linux/man-pages/man2/write.2.html <code>write(2)</code>]. For now, it is enough to know that <code>lseek(fd, 0, SEEK_END)</code> returns the size of the file.

The following program prints a file, by mapping it into memory and writing the memory to the standard output:

<syntaxhighlight lang="c">
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <unistd.h>

static void print_error(const char *what)
{
char msg[256];
snprintf(msg, sizeof msg, "%s: %s\n", what, strerror(errno));
write(STDERR_FILENO, msg, strlen(msg));
}

int main(int argc, char **argv)
{
if (argc != 2) {
const char usage[] = "Usage: app FILE\n";
write(STDERR_FILENO, usage, strlen(usage));
return EXIT_FAILURE;
}

int fd = open(argv[1], O_RDONLY);
if (fd == -1) {
print_error(argv[1]);
return EXIT_FAILURE;
}

// The offset of the end of the file is its size.
off_t size = lseek(fd, 0, SEEK_END);
if (size == -1) {
print_error("lseek");
return EXIT_FAILURE;
}

char *p = mmap(nullptr, size, PROT_READ, MAP_PRIVATE, fd, 0);
if (p == MAP_FAILED) {
print_error("mmap");
return EXIT_FAILURE;
}

// The mapping stays valid after the file descriptor is closed.
close(fd);

// The whole file is now an array of bytes in memory.
write(STDOUT_FILENO, p, size);

munmap(p, size);
return EXIT_SUCCESS;
}
</syntaxhighlight>

<div class="regula">'''Note:''' A mapping cannot be empty: [https://man7.org/linux/man-pages/man2/mmap.2.html <code>mmap(2)</code>] of an empty file fails with <code>EINVAL</code> (''Invalid argument'').</div>

<div class="regula">'''Note:''' The size of a file can be changed with [https://man7.org/linux/man-pages/man2/truncate.2.html <code>truncate(2)</code>], given its path, or [https://man7.org/linux/man-pages/man2/ftruncate.2.html <code>ftruncate(2)</code>], given a file descriptor open for writing:

<syntaxhighlight lang="c">
// In: <unistd.h>
int truncate(const char *path, off_t length);
int ftruncate(int fd, off_t length);
</syntaxhighlight>
</div>

Mapping a file is especially convenient for files with a binary structure: a pointer into the mapping can be cast to a pointer to a C <code>struct</code>, and the fields read directly, as we will do with the ELF file below.

=== Anonymous mmap(2) ===

With the <code>MAP_ANONYMOUS</code> flag, [https://man7.org/linux/man-pages/man2/mmap.2.html <code>mmap(2)</code>] maps no file at all. The <code>fd</code> argument must be <code>-1</code> and <code>offset</code> must be 0, and the kernel gives the process new memory, filled with zeros:

<syntaxhighlight lang="c" line>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <unistd.h>

int main(void)
{
size_t size = 1024 * 1024; // 1 MiB

char *buf = mmap(nullptr, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (buf == MAP_FAILED) {
char msg[256];
snprintf(msg, sizeof msg, "mmap: %s\n", strerror(errno));
write(STDERR_FILENO, msg, strlen(msg));
return EXIT_FAILURE;
}

// The new memory is filled with zeros.
snprintf(buf, size, "Got %zu bytes at %p, the last one is %d\n", size, (void *) buf, buf[size - 1]);
write(STDOUT_FILENO, buf, strlen(buf));

munmap(buf, size);
return EXIT_SUCCESS;
}
</syntaxhighlight>

<syntaxhighlight lang="bash">
$ ./build/debug/app
Got 1048576 bytes at 0xffff98360000, the last one is 0
</syntaxhighlight>

This is how the program gets memory from the kernel: [https://man7.org/linux/man-pages/man3/malloc.3.html <code>malloc(3)</code>] itself uses anonymous mappings for large allocations (by default, 128 KiB and more), and carves the smaller ones out of bigger regions.

<div class="regula">'''Note:''' The kernel only reserves the virtual addresses at first. A physical page is given to the process the first time it touches each page, so a mapping of 1 GiB that is never used costs almost nothing.</div>

=== read(2), write(2) and lseek(2) ===

The second way to get to the data in a file is the '''explicit''' one: the program provides a buffer in its own memory, and asks the kernel to copy data from the file into it, or from it into the file.

<syntaxhighlight lang="c">
// In: <unistd.h>
ssize_t read(int fd, void *buf, size_t count);
ssize_t write(int fd, const void *buf, size_t count);
</syntaxhighlight>

[https://man7.org/linux/man-pages/man2/read.2.html <code>read(2)</code>] copies at most <code>count</code> bytes from the file into <code>buf</code>, and returns the number of bytes it copied:

* a positive number, which may be '''less''' than <code>count</code>: for a regular file, only near its end; for a terminal or a pipe, whenever less data is available;
* <code>0</code>, at the end of the file;
* <code>-1</code>, on error.

[https://man7.org/linux/man-pages/man2/write.2.html <code>write(2)</code>] works the same way in the other direction. It may also write fewer bytes than asked (for example, when the disk is full), in which case the program must call it again for the rest.

Each open file has a '''current offset''': the position in the file where the next [https://man7.org/linux/man-pages/man2/read.2.html <code>read(2)</code>] or [https://man7.org/linux/man-pages/man2/write.2.html <code>write(2)</code>] starts. It begins at 0 when the file is opened, and every [https://man7.org/linux/man-pages/man2/read.2.html <code>read(2)</code>] or [https://man7.org/linux/man-pages/man2/write.2.html <code>write(2)</code>] moves it forward by the number of bytes it copied. The program can also move it explicitly:

<syntaxhighlight lang="c">
// In: <unistd.h>
off_t lseek(int fd, off_t offset, int whence);
</syntaxhighlight>

{| class="wikitable"
! <code>whence</code> !! The new offset is
|-
| <code>SEEK_SET</code> || <code>offset</code>
|-
| <code>SEEK_CUR</code> || the current offset + <code>offset</code>
|-
| <code>SEEK_END</code> || the size of the file + <code>offset</code>
|}

[https://man7.org/linux/man-pages/man2/lseek.2.html <code>lseek(2)</code>] returns the new offset. This is why <code>lseek(fd, 0, SEEK_END)</code>, which we used in the [https://man7.org/linux/man-pages/man2/mmap.2.html <code>mmap(2)</code>] example above, returns the size of the file.

[[File:OS_Lab_3_-_file_offset.png|center|thumb|525px|The current offset of an open file: [https://man7.org/linux/man-pages/man2/read.2.html <code>read(2)</code>] moves it forward by the number of bytes it read, and [https://man7.org/linux/man-pages/man2/lseek.2.html <code>lseek(2)</code>] sets it directly.]]

<div class="regula">'''Note:''' The offset belongs to the open file, not to the file itself (see the file descriptor table above). Two [https://man7.org/linux/man-pages/man2/open.2.html <code>open(2)</code>] calls on the same file give two independent offsets.</div>

The following program prints a file, like the [https://man7.org/linux/man-pages/man2/mmap.2.html <code>mmap(2)</code>] example above, this time copying it in pieces of up to 4 KiB, until [https://man7.org/linux/man-pages/man2/read.2.html <code>read(2)</code>] reports the end of the file:

<syntaxhighlight lang="c" line>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

static void print_error(const char *what)
{
char msg[256];
snprintf(msg, sizeof msg, "%s: %s\n", what, strerror(errno));
write(STDERR_FILENO, msg, strlen(msg));
}

int main(int argc, char **argv)
{
if (argc != 2) {
const char usage[] = "Usage: app FILE\n";
write(STDERR_FILENO, usage, strlen(usage));
return EXIT_FAILURE;
}

int fd = open(argv[1], O_RDONLY);
if (fd == -1) {
print_error(argv[1]);
return EXIT_FAILURE;
}

char buf[4096];
ssize_t n;
while ((n = read(fd, buf, sizeof buf)) > 0) {
if (write(STDOUT_FILENO, buf, n) == -1) {
print_error("write");
return EXIT_FAILURE;
}
}
if (n == -1) {
print_error("read");
return EXIT_FAILURE;
}

close(fd);
return EXIT_SUCCESS;
}
</syntaxhighlight>

Unlike the [https://man7.org/linux/man-pages/man2/mmap.2.html <code>mmap(2)</code>] version, this one also works for an empty file. Like the [https://man7.org/linux/man-pages/man2/mmap.2.html <code>mmap(2)</code>] version, it fails on a directory: <code>read: Is a directory</code>.

=== readdir(3) ===

As we saw in the course, a '''directory''' is a special file which maps names to '''inode numbers'''. Its entries are not read with [https://man7.org/linux/man-pages/man2/read.2.html <code>read(2)</code>], but with the [https://man7.org/linux/man-pages/man2/getdents64.2.html <code>getdents64(2)</code>] system call, which fills a buffer with as many entries as fit. ''glibc'' provides the following interface on top of it:

<syntaxhighlight lang="c">
// In: <dirent.h>
DIR *opendir(const char *name);
struct dirent *readdir(DIR *dirp);
int closedir(DIR *dirp);
</syntaxhighlight>

[https://man7.org/linux/man-pages/man3/opendir.3.html <code>opendir(3)</code>] opens the directory and returns a <code>DIR</code> structure, which holds the file descriptor and a buffer of entries. Each call to [https://man7.org/linux/man-pages/man3/readdir.3.html <code>readdir(3)</code>] returns the next entry, calling [https://man7.org/linux/man-pages/man2/getdents64.2.html <code>getdents64(2)</code>] again when the buffer runs out, and returns <code>nullptr</code> after the last one.

<syntaxhighlight lang="c">
// In: <dirent.h> (simplified)
struct dirent {
ino_t d_ino; // The inode number
off_t d_off; // Used internally
unsigned short d_reclen; // Used internally
unsigned char d_type; // The type of the file
char d_name[256]; // The name, '\0'-terminated
};
</syntaxhighlight>

[[File:OS_Lab_3_-_dirent.png|center|thumb|600px|A directory is a list of (name, inode number) entries. Each call to [https://man7.org/linux/man-pages/man3/readdir.3.html <code>readdir(3)</code>] returns the next one, in the order the file system keeps them.]]

The entries come in the order the file system stores them, which is not alphabetical, and include <code>.</code> (the directory itself) and <code>..</code> (its parent). The <code>d_type</code> field holds one of <code>DT_REG</code> (regular file), <code>DT_DIR</code> (directory), <code>DT_LNK</code> (symbolic link), <code>DT_FIFO</code> (pipe), <code>DT_CHR</code> (character device), <code>DT_BLK</code> (block device), <code>DT_SOCK</code> (socket), or <code>DT_UNKNOWN</code> if the file system does not provide it.

The following program prints the names in the current directory:

<syntaxhighlight lang="c">
#include <dirent.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

static void print_error(const char *what)
{
char msg[256];
snprintf(msg, sizeof msg, "%s: %s\n", what, strerror(errno));
write(STDERR_FILENO, msg, strlen(msg));
}

int main(void)
{
DIR *dir = opendir(".");
if (dir == nullptr) {
print_error(".");
return EXIT_FAILURE;
}

struct dirent *entry;
errno = 0;
while ((entry = readdir(dir)) != nullptr) {
write(STDOUT_FILENO, entry->d_name, strlen(entry->d_name));
write(STDOUT_FILENO, "\n", 1);
}
// nullptr means either "no more entries" or an error: only an error sets errno.
if (errno != 0) {
print_error("readdir");
return EXIT_FAILURE;
}

closedir(dir);
return EXIT_SUCCESS;
}
</syntaxhighlight>

<div class="regula">'''Note:''' <code>ls</code> sorts the names before printing them. <code>ls -f</code> prints them unsorted, in the same order as the program above.</div>

To check inode numbers from the shell, use <code>ls -i</code> or <code>stat</code>:

<syntaxhighlight lang="bash">
$ ls -i notes.txt
645260 notes.txt
$ stat -c '%i %n' notes.txt
645260 notes.txt
</syntaxhighlight>

== The ELF file ==

Executable files and shared libraries on Linux use the '''ELF''' format (''Executable and Linkable Format''). It is a binary format, described by the structures in <code><elf.h></code>. We will only look at the parts the kernel needs to start a program.

<syntaxhighlight lang="bash">
$ readelf -h build/debug/app # the ELF header
$ readelf -l build/debug/app # the program headers
</syntaxhighlight>

=== The ELF header ===

Every ELF file starts with the '''ELF header''', at offset 0:

<syntaxhighlight lang="c">
// In: <elf.h> (simplified)
typedef struct {
unsigned char e_ident[16]; // "\x7f" "ELF", then the class, byte order, ...
uint16_t e_type; // Executable, shared library, ...
uint16_t e_machine; // The architecture: x86-64, AArch64, RISC-V, ...
uint32_t e_version;
uint64_t e_entry; // The entry point (see the last lab)
uint64_t e_phoff; // File offset of the program header table
uint64_t e_shoff; // File offset of the section header table
uint32_t e_flags;
uint16_t e_ehsize; // Size of this header
uint16_t e_phentsize; // Size of one program header
uint16_t e_phnum; // Number of program headers
uint16_t e_shentsize;
uint16_t e_shnum;
uint16_t e_shstrndx;
} Elf64_Ehdr;
</syntaxhighlight>

The first 4 bytes are always <code>0x7f</code>, <code>'E'</code>, <code>'L'</code>, <code>'F'</code>. The next byte, <code>e_ident[EI_CLASS]</code>, is <code>ELFCLASS64</code> for 64-bit programs.

<syntaxhighlight lang="bash">
$ readelf -h build/debug/app
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
...
Machine: AArch64
...
Start of program headers: 64 (bytes into file)
...
Size of program headers: 56 (bytes)
Number of program headers: 10
...
</syntaxhighlight>

=== The program headers ===

The '''program header table''' is an array of <code>e_phnum</code> entries, each <code>e_phentsize</code> bytes long, starting at offset <code>e_phoff</code> in the file. Each entry describes a '''segment''': a range of bytes in the file and what the kernel should do with it.

<syntaxhighlight lang="c">
// In: <elf.h>
typedef struct {
uint32_t p_type; // The kind of segment: PT_LOAD, PT_INTERP, ...
uint32_t p_flags; // Permissions: PF_R, PF_W, PF_X
uint64_t p_offset; // Where the segment starts in the file
uint64_t p_vaddr; // Where it goes in virtual memory
uint64_t p_paddr; // Unused
uint64_t p_filesz; // Its size in the file
uint64_t p_memsz; // Its size in memory (larger for .bss)
uint64_t p_align;
} Elf64_Phdr;
</syntaxhighlight>

Common segment types:

{| class="wikitable"
! <code>p_type</code> !! Value !! Description
|-
| <code>PT_LOAD</code> || 1 || A range of the file to map into memory (<code>.text</code>, <code>.rodata</code>, <code>.data</code>, <code>.bss</code>, ...)
|-
| <code>PT_DYNAMIC</code> || 2 || Information for the dynamic loader: which shared libraries to load, ...
|-
| <code>PT_INTERP</code> || 3 || The path of the program interpreter (the dynamic loader)
|-
| <code>PT_NOTE</code> || 4 || Auxiliary information (for example, a unique build ID)
|-
| <code>PT_PHDR</code> || 6 || The program header table itself
|}

==== PT_INTERP ====

As we saw in the [[OS_Lab_2_-_System_calls._The_initial_stack|last lab]], most programs are '''dynamically linked''': the code of the libraries they use (such as ''glibc'') is not in the executable file, and must be loaded when the program starts. When the kernel finds a <code>PT_INTERP</code> segment in a program, it also loads the program named there, the '''dynamic loader''', and starts it instead of the program. The loader then loads the libraries and jumps to the program's entry point.

The <code>PT_INTERP</code> segment is a <code>'\0'</code>-terminated string of <code>p_filesz</code> bytes (the <code>'\0'</code> included), at offset <code>p_offset</code> in the file:

[[File:OS_Lab_3_-_elf_interp.png|center|thumb|600px|Finding <code>PT_INTERP</code>: the ELF header gives the position of the program header table, and the <code>PT_INTERP</code> entry gives the position of the string.]]

<syntaxhighlight lang="bash">
$ readelf -l build/debug/app
...
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x0000000000000230 0x0000000000000230 R 0x8
INTERP 0x0000000000000294 0x0000000000000294 0x0000000000000294
0x000000000000001b 0x000000000000001b R 0x1
[Requesting program interpreter: /lib/ld-linux-aarch64.so.1]
...
</syntaxhighlight>

On x86-64, the dynamic loader is <code>/lib64/ld-linux-x86-64.so.2</code>.

<div class="regula">'''Note:''' Statically linked programs contain all the library code they need, and have no <code>PT_INTERP</code> segment: the kernel jumps directly to their entry point.</div>

== Exercises ==

Write each program in its own copy of the project template. As a reminder from [[OS_Lab_1_-_Linux_setup._Bash_primer._C_primer#getting-the-template|the first lab]]:

<syntaxhighlight lang="bash">
mkdir -p ~/oslab && cd ~/oslab
curl -OL https://wiki.dcae.pub.ro/images/9/93/Os_lab_skeleton.zip
unzip -d lab03 Os_lab_skeleton.zip
</syntaxhighlight>

Use a new directory name instead of <code>interp_mmap</code> for each exercise.

For this lab:

* Use the ''glibc'' wrappers for the system calls ([https://man7.org/linux/man-pages/man2/open.2.html <code>open(2)</code>], [https://man7.org/linux/man-pages/man2/read.2.html <code>read(2)</code>], [https://man7.org/linux/man-pages/man2/write.2.html <code>write(2)</code>], [https://man7.org/linux/man-pages/man2/lseek.2.html <code>lseek(2)</code>], [https://man7.org/linux/man-pages/man2/mmap.2.html <code>mmap(2)</code>], ...), instead of [https://man7.org/linux/man-pages/man2/syscall.2.html <code>syscall(2)</code>].
* Do not use the standard I/O library: no <code>FILE</code>, [https://man7.org/linux/man-pages/man3/printf.3.html <code>printf(3)</code>], [https://man7.org/linux/man-pages/man3/puts.3.html <code>puts(3)</code>], [https://man7.org/linux/man-pages/man3/fopen.3.html <code>fopen(3)</code>], [https://man7.org/linux/man-pages/man3/fread.3.html <code>fread(3)</code>] and so on. [https://man7.org/linux/man-pages/man3/snprintf.3.html <code>snprintf(3)</code>] is still fine, and recommended, for building a string that you then [https://man7.org/linux/man-pages/man2/write.2.html <code>write(2)</code>].
* [https://man7.org/linux/man-pages/man3/opendir.3.html <code>opendir(3)</code>], [https://man7.org/linux/man-pages/man3/readdir.3.html <code>readdir(3)</code>] and [https://man7.org/linux/man-pages/man3/closedir.3.html <code>closedir(3)</code>] should be used for exercise C.

=== A. PT_INTERP with mmap(2) ===

Print the path of the dynamic loader of your own program. Open the executable file, using <code>argv[0]</code> as its path, map the whole file into memory with [https://man7.org/linux/man-pages/man2/mmap.2.html <code>mmap(2)</code>], then walk the program headers to find the <code>PT_INTERP</code> segment, and print its string.

<syntaxhighlight lang="bash">
$ ./build/debug/app
/lib/ld-linux-aarch64.so.1
$ readelf -l build/debug/app | grep interpreter
[Requesting program interpreter: /lib/ld-linux-aarch64.so.1]
</syntaxhighlight>

Your output will be different on x86-64.

* Cast the start of the mapping to <code>const Elf64_Ehdr *</code>. The program headers are an array of <code>Elf64_Phdr</code> at <code>e_phoff</code> bytes from the start.
* Check that the file starts with <code>[0x7f, 'E', 'L', 'F']</code> before looking further.
* If there is no <code>PT_INTERP</code> segment, say so on standard error and exit with status 1.

'''Extra:''' <code>argv[0]</code> is not always trustworthy as the location of the executable. Where does the kernel offer us this information direcly?

=== B. PT_INTERP with read(2) and lseek(2) ===

Write the same program again, without [https://man7.org/linux/man-pages/man2/mmap.2.html <code>mmap(2)</code>]-ing the file: read the ELF header with [https://man7.org/linux/man-pages/man2/read.2.html <code>read(2)</code>], then use [https://man7.org/linux/man-pages/man2/lseek.2.html <code>lseek(2)</code>] to move to the program headers and read them, and finally move to the <code>PT_INTERP</code> segment and read the string. The two programs must print the same thing.

* The size of the program header table is only known at run time (<code>e_phnum * e_phentsize</code> bytes). Allocate the buffer for it with an anonymous [https://man7.org/linux/man-pages/man2/mmap.2.html <code>mmap(2)</code>], and [https://man7.org/linux/man-pages/man2/munmap.2.html <code>munmap(2)</code>] it when you are done.
* [https://man7.org/linux/man-pages/man2/read.2.html <code>read(2)</code>] may return fewer bytes than you asked for. Check that you got everything you need: for a regular file, getting less means the file is shorter than its headers say.

'''Extra:''' compare the system calls the two versions make, with <code>strace ./build/debug/app</code> (install it with <code>sudo apt install strace</code>). The ones at the start belong to the dynamic loader and to ''glibc''; look for <code>openat</code> and what comes after it.

=== C. Inode numbers with readdir(3) ===

Write a command which takes the name of a file in the current working directory and prints its inode number. Find it by reading the directory with [https://man7.org/linux/man-pages/man3/readdir.3.html <code>readdir(3)</code>], not with [https://man7.org/linux/man-pages/man2/stat.2.html <code>stat(2)</code>].

<syntaxhighlight lang="bash">
$ echo hi > notes.txt
$ ./build/debug/app notes.txt
645260
$ ls -i notes.txt
645260 notes.txt
$ ./build/debug/app nope
nope: No such file or directory
$ echo $?
1
</syntaxhighlight>

Some things to look at:

* Make a hard link with <code>ln notes.txt other.txt</code> and a symbolic link with <code>ln -s notes.txt link.txt</code>. What inode numbers do they have, and why?
* What are the inode numbers of <code>.</code> and <code>..</code>?

'''Extra:''' also print the type of the file, from <code>d_type</code>: <code>regular file</code>, <code>directory</code>, <code>symbolic link</code>, ...

@@ Linia 450: / Linia 450: @@
 == The ELF file ==
-Executable files and shared libraries on Linux use the '''ELF''' format (''Executable and Linkable Format'': [https://man7.org/linux/man-pages/man5/elf.5.html <code>syscall(2)</code>]). It is a binary format, described by the structures in <code>&lt;elf.h&gt;</code>. We will only look at the parts the kernel needs to start a program.
+Executable files and shared libraries on Linux use the '''ELF''' format (''Executable and Linkable Format'': [https://man7.org/linux/man-pages/man5/elf.5.html <code>elf(5)</code>]). It is a binary format, described by the structures in <code>&lt;elf.h&gt;</code>. We will only look at the parts the kernel needs to start a program.
 <syntaxhighlight lang="bash">

@@ Linia 450: / Linia 450: @@
 == The ELF file ==
-Executable files and shared libraries on Linux use the '''ELF''' format (''Executable and Linkable Format''). It is a binary format, described by the structures in <code>&lt;elf.h&gt;</code>. We will only look at the parts the kernel needs to start a program.
+Executable files and shared libraries on Linux use the '''ELF''' format (''Executable and Linkable Format'': [https://man7.org/linux/man-pages/man5/elf.5.html <code>syscall(2)</code>]). It is a binary format, described by the structures in <code>&lt;elf.h&gt;</code>. We will only look at the parts the kernel needs to start a program.
 <syntaxhighlight lang="bash">

OS Lab 3 - Files. Memory mapping - Revizia istoricului

Vserbu: /* The ELF file */

Vserbu: /* The ELF file */

Vserbu: Pagină nouă: In the last lab, we saw how a user-space program asks the kernel for services through '''system calls''', and what the kernel places...