Programs Asking Linux for Help

How Programs WorkLesson 7 of 760 minutesLab included

Learning objectives

By the end of this lesson

• Explain the distinction between userspace code, library functions, and system calls.
• Use strace to observe file, memory, output, and process-exit activity.
• Connect selected system calls to higher-level program behavior.
• Filter a trace without claiming an omitted event never occurred.

A process cannot do everything by itself

Ordinary programs run in userspace, where the processor prevents them from directly controlling protected hardware and kernel memory. When a program needs an operating-system service—opening a file, creating a mapping, writing output, or exiting—it makes a system call.

A C library function is not automatically a system call. printf performs formatting in userspace and eventually relies on a system call such as write to send bytes to an output stream. malloc manages allocations and requests more memory from Linux only when its existing pool is insufficient.

Install and use strace

Check for the tracing tool:

strace --version

If it is missing:

sudo apt update
sudo apt install strace

Trace a simple command and save the evidence:

strace -o echo.trace /usr/bin/echo hello
less echo.trace

The command prints one friendly line. The trace contains loader activity, memory mappings, locale files, output, and process termination. Simple source behavior can require substantial runtime preparation.

Search for execve, openat, mmap, write, and exit_group. A typical trace line shows a system call name, arguments, and a return value after =. A negative return with an error name such as ENOENT is evidence of a failed attempt; programs often try several possible files during normal startup.

Knowledge check

Question 1 of 2

Is printf itself necessarily a Linux system call?

No, it is a library function that may eventually use system callsYes, every C function enters the kernelOnly when printing numbers

Check answer

Reduce noise carefully

Filter the trace to selected calls:

strace -e trace=execve,openat,mmap,write,exit_group /usr/bin/echo hello

Filtering helps answer a focused question. It also hides everything outside the filter. Write “the filtered trace showed no additional writes,” not “the program made no other system calls.” Precision about observation limits is part of the job.

Capture strings written by a program:

strace -e trace=write -s 200 /usr/bin/echo hello

-s 200 raises the displayed string limit. It does not make arbitrary binary data safe or meaningful as text.

Trace the lifetime example

strace -o lifetime.trace ./lifetime
grep -E 'brk|mmap|munmap|write|exit_group' lifetime.trace

You may not see one kernel call for each malloc and free. The allocator reuses and manages larger regions. This is useful evidence that the C allocation interface and kernel memory interface are related layers, not identical operations.

Checkpoint

Build a behavior timeline

Using the trace, record the first executable request, one mapped file, the call that writes visible output, and the final exit call. For each conclusion, quote the relevant trace line and explain what it establishes.

What this gives us as researchers

You can now observe where a program asks Linux to act and distinguish that boundary from the source-level function that led there. The final lab combines ELF metadata, process mappings, disassembly, calls, memory lifetime, and system calls into one bounded investigation.