DEV Community: Beka Modebadze

LLVM Infrastructure and Rust

Beka Modebadze — Thu, 23 Dec 2021 23:22:34 +0000

You can find original post on my blog.

LLVM is an engine behind many programming languages. It's used by C, C++, Rust, Go, Swift and others. This log is all about LLVM and I'll explore following topics:

What is LLVM Infrastructure
How LLVM Works
LLVM's Program Structure
LLVM and Rustc

What is LLVM Infrastructure

LLVM Infrastructure is a collection of modular and reusable compiler and toolchain technologies. LLVM umbrella contains several sub-projects like Clang, C/C++/Objective-C compiler, Debugger LLDB, libc++, etc. Decades of research and improvement created an amazing tool for building languages and compilers, which some of the modern technologies are taking advantage of.

LLVM project started in 2000 at the University of Illinois at Urbana-Champaign, by Vikram Adve and Chris Lattner. LLVM's name initially was the acronym for Low-Level Virtual Machine. Even though modern LLVM Infrastructure has nothing to do with virtual machines the name remained unchanged. But the abbreviation itself was later removed and LLVM became the full name of the project.

The LLVM Project was released under the Open Source License. Later Lattner was hired by Apple, and the whole team was assigned to work on the LLVM system for several uses within Apple products. LLVM started expanding its features and grew into an umbrella project which combines LLVM IR, LLVM Debugger, and LLVM API C++ Library.

LLVM Compiler Framework is a modular and reusable compiler framework using LLVM infrastructure to provide the end-to-end compilation of code. It is used to build, optimize, sanitize, and produce intermediate code (IR) or binary (machine) code (BC). LLVM allows the translation of programming language code into the intermediate representation (IR) which can be converted into binary code (BC) for any given hardware architecture. IR language is independent of the source and target languages.

LLVM is used in multiple ways. The main way it can be used is as a compiler framework. Here you provide, what's called, the front end and the back end, or machine code and it produces the IR. This IR can be converted into binary code and linked into machine-dependent assembly language for the target platform.

LLVM's intermediate representation (IR) is a low-level programming language similar to assembly. But in addition to assembly, it provides better type annotation and human-friendly syntax. Also, IR uses an infinite set of registered instead of a predefined number of registers. We will explore IR's internal workings in a later segment.

How LLVM Works

As mentioned already LLVM is a modular and reusable compiler framework that supports multiple front-ends and back-ends. The lifecycle of the program consists of writing a source code and then compiling it into binary code for execution. Our point of interest is the compiler stage. When source code is compiled into binary it goes through several steps in a subsequent order.

The compilation process can be divided into three parts. Front-End, Optimization, Back-End (Fig. 1-a). The compilation process starts on the front end. First, Pre-Processor starts to organize the source code. This is the phase when external libraries are extended into the target source code. In Rust, this directive is defined by the use statement. A similar directive in C and C++ is #include statement.

Figure 1-a. Program's Lifecycle

Second, is Parsing. At this stage the code is evaluated for the syntatic errors and the Abstract Syntax Tree (AST) is built. Third step at the front-end compilation is IR Generation. At this step compiler converts AST to the intermediate representation (IR) and outputs the result.

At the Optimization stage the compiler performs various transformations and sanitization to the program. This improves program performance, secures it by preventing various bugs, and does some utility runs. Later we'll explore IR and look at some optimization passes that come with compilers.

After the program is optimized it goes in the back-end stage. Here, Compiler Back-End converts IR to the target-specific assembly code. Then Assembler converts target-specific assembly code to target-specific machine code. And finally, Linker combines multiple machine code files into a single image, what we refer to as executable.

There are several language-specific Front ends. We have clang for C and C++, Go has gollvm, and Rust has it's compiler called rustc. Similarly after LLVM IR's optimizer passes code is converted into architecture-specific back-ends, like x86, ARM, MIPS.

The part between the front-end and back-end, called optimizer is where the magic of code optimization and sanitization happens. This is done through the series of what's called Pass. Each pass run one after another and there can be N number of passes. Passes can be categorized into two groups: Analysis and Transfromation. Analysis pass analyzes IR to check program properties, while Transformation pass transforms IR to monitor and optimize the program.

When source code is converted into LLVM IR it can take one of three formats (Figure 1-b). In-memory format is a binary which is suitable for front-ends during the compilation process. Other two formats are Bitcode and Assembly. Bitcode is a binary on-disk stored format, suitable for fast loading as it's more memory efficient. Assembly is a textual format for human readability.

Figure 1-b. LLVM IR Formats

You may want to know why to use IR/BC instead of Native Assembly and Native binary? The reason is Native assembly has one-to-one binding to the platform's machine code. It depends on the target's architecture, for example, the program's assembly for the x86 and assembly for ARM will be different. Native assembly is turned into native binary via assembler, the feature that LLVM also includes. Here is the extensive list of LLVM passes available out of box. But that's not all of it, you can implement your passes to sanitize, or optimize source code.

LLVM's Program Structure

LLVM IR, just like any other system, has its program structure (Fig. 2-a). The top-level container is a Module that corresponds to each translation unit of the front-end compiler. Module can consist of one or many functions. Each function has one or many basic blocks, which has instructions. Instruction is a single line and there are multiple instructions available in the IR language.

You can get the .ll (IR assembly) file from your Rust source code by running following command in the terminal:

$ rustc someprogram.rs --emit=llvm-ir -o somename.ll

Here we tell to rustc compiler to give us llvm-ir (this is done by the flag --emit=llvm-ir) form for the someprogram.rs and output it (using option -o) as someoname.ll. Similarly, you can emit bitcode by using --emit=llvm-bc flag.

The actual program structure in LLVM IR consists of hierarchical containers. At the top level, you have Module. It corresponds to each translation unit of the front-end compiler. Modules may be combined with the LLVM linker, which merges function definitions. Function is a next-level container, that includes function signature and its basic blocks. Basic Block is a set of instructions that are executed sequentially. Basic blocks have one entry and one exit. The first block is called the entry block. Finally, IR has instructions. Instructions are a single line executables (Figure 2-a).

Figure 2-a. IR Program Structure

In the IR file you'll encounter two kinds of variables, local variables, indicated with % symbol and global variables, indicated with @ symbol. LLVM IR can use an infinite number of temporary registers, instead of a predefined number of registers, as native assemblers do. IR's registers are defined by integer numbers, like 1,2,3,..N. For example, %2 = load i32, i32* %x means that value that is stored at the address of the local variable x is loaded into the temporary register 2.

Another advantage of LLVM IR is that it utilizes what's called Static Single Assignment (SSA) form. This allows various optimizations to be done on a code. Instead of regular variables that can be reassigned multiple times, SSA variables can only be assigned once. This allows compilers to do more efficient register allocation because it's easy to approximate a number of live variables at any given point. It can detect unused variables and prevent programs from unnecessary pointer allocation.

For example, the following code x = x * x in an SSA form will be x_2 := x_1 * x_1. If we get into the loop where the variable constantly gets a new value, SSA uses what's called Phi Nodes. Phi will merge the variables into the final value that will be returned/outputted from the branch or loop. We'll look at concrete examples and go over IR syntax in the next segment of this log.

LLVM and Rustc

The official guide to the Rustc development has all the reasons listed of why they are using LLVM, which I'm reciting directly:

We don't have to write a whole compiler backend. This reduces the implementation and maintenance burden.
We benefit from the large suite of advanced optimizations that the LLVM project has been collecting.
We can automatically compile Rust to any of the platforms for which LLVM has support. For example, as soon as LLVM added support for wasm, voila! rustc, clang, and a bunch of other languages were able to compile to wasm! (Well, there was some extra stuff to be done, but we were 90% there anyway).
We and other compiler projects benefit from each other. For example, when the Spectre and Meltdown security vulnerabilities were discovered, only LLVM needed to be patched.

Now, as we got familiar with what LLVM IR is, what id does, and why so many compilers are built on it, it's time to get our hands dirty and explore IR's internals using a simple Rust program called simple1.rs:

//simple1.rs

fn square(x: u32) -> u32 {
    x * x
}

fn factorial(mut n: u32) -> u32 {
    let mut acc = 1u32;
    while n > 0 {
        acc *= n;
        n = n - 1;
    }
     acc
}
    
fn main() {
    let s = square(4);
    let f = factorial(s);
}

Our program has three functions, main function that is an entry point in our program, square function that returns the square of a given number, and factorial that calculates factorial of the supplied integer. We output the LLVM IR file by invoking the following command in the terminal:

>$ rustc simple1.rs --emit=llvm-ir

Now we should have simple1.ll in the same folder as our source code. Let's open the .ll file in the text editor and start exploring. At the beginning of the file, you'll find a bunch of metadata and other information and directives related to the program, but we are interested in delving into how our Rust functions are translated to IR, and we'll start doing it by first looking at square function.

Search for the line which has a comment simple1::square and next to it you'll find the LLVM IR container of a give function. Which looks like this:

; simple1::square
; Function Attrs: nonlazybind uwtable
define internal i32 @_ZN7simple16square17h74fdb775aec225a0E(i32 %x) unnamed_addr #1 {
start:
  %0 = call { i32, i1 } @llvm.umul.with.overflow.i32(i32 %x, i32 %x)
  %_4.0 = extractvalue { i32, i1 } %0, 0
  %_4.1 = extractvalue { i32, i1 } %0, 1
  %1 = call i1 @llvm.expect.i1(i1 %_4.1, i1 false)
  br i1 %1, label %panic, label %bb1

bb1:                                              ; preds = %start
  ret i32 %_4.0

panic:                                            ; preds = %start
; call core::panicking::panic
  call void @_ZN4core9panicking5panic17h50b51d19800453c0E([0 x i8]* ...
}

IR starts by defining function with a randomly generated unique name (that also includes original function name in it) that returns i32 value and takes i32 value as a parameter. The start is the label for the entry point of the function. In the first instruction LLVM IR calls its intrinsic function @llvm.umul.with.overflow.i32. This function takes two i32 arguments (in this case both ar x), performs unsigned multiplication and outputs tuple-like result, where first value is i32 and the second value is i1. The result is assigned to a unnamed temporary %0.

You may ask here a couple of questions. First, why does the square function take and return the i32 value instead of the u32 value as was declared In the source code? LLVM IR doesn't provide separately defined data types for signed and unsigned values. Instead, it performs operations specific to the value type, signed operation for signed values, unsigned operations for unsigned values. If our square function took i32 as an argument and returned i32, IR would have called @llvm.smul.with.overflow.i32 instead, which is an intrinsic function for signed multiplication.

The next question you may ask is why does multiplying an integer over an integer returns a tuple? If you look at the types of the outputted tuple, the second item is an i1 (a single bit value), which is for binary/boolean values. The name of the called function suggests that it does unsigned multiplication with overflow. If the overflow is detected, that is multiplied value exceeds the maximum unsigned value 32 bits can hold, because we performed unsigned multiplication, it sets i1 to 1, e.g. true.

In two following instructions IR unpacks the result of multiplication. The unnamed temporary %_4.0 takes the multiplied value and the boolean result is assigned to %_4.1. Next, IR calls another intrinsic function @llvm.expect.i1(i1 %_4.1, i1 false) where it expects value assigned to unnamed temporary %_4.1 to be false. Program assigns evaluated result to another unnamed temporary %1. Unnamed temporaries are unsigned numeric values with prefix % or @ (example, %1) created by IR. Named values are represented as string characters with similar prefixes introduced from a source code (example %acc).

After that, IR performs branching. The br directive checks if the value placed in temporary %1 is true, and if so jumps to %panic, otherwise to %bb1. Two above mentioned names are labels for the basic blocks. The %panic calls Rust's panic method (if you have programmed in Rust you should know what panic does), while bb1 returns value stored in temporary %_4.0 from the function square.

Now, let's look at our factorial function, as there are more interesting things happening:

; simple1::factorial
; Function Attrs: nonlazybind uwtable
define internal i32 @_ZN7simple19factorial17hceebae2a8a73b808E(i32 %0) unnamed_addr #1 {
start:
  %acc = alloca i32, align 4
  %n = alloca i32, align 4
  store i32 %0, i32* %n, align 4
  store i32 1, i32* %acc, align 4
  br label %bb1

bb1:                                              ; preds = %bb4, %start
  %_3 = load i32, i32* %n, align 4
  %_2 = icmp ugt i32 %_3, 0
  br i1 %_2, label %bb2, label %bb5

bb5:                                              ; preds = %bb1
  %1 = load i32, i32* %acc, align 4
  ret i32 %1

bb2:                                              ; preds = %bb1
  %_4 = load i32, i32* %n, align 4
  %2 = load i32, i32* %acc, align 4
  %3 = call { i32, i1 } @llvm.umul.with.overflow.i32(i32 %2, i32 %_4)
  %_5.0 = extractvalue { i32, i1 } %3, 0
  %_5.1 = extractvalue { i32, i1 } %3, 1
  %4 = call i1 @llvm.expect.i1(i1 %_5.1, i1 false)
  br i1 %4, label %panic, label %bb3

bb3:                                              ; preds = %bb2
  store i32 %_5.0, i32* %acc, align 4
  %_6 = load i32, i32* %n, align 4
  %5 = call { i32, i1 } @llvm.usub.with.overflow.i32(i32 %_6, i32 1)
  %_7.0 = extractvalue { i32, i1 } %5, 0
  %_7.1 = extractvalue { i32, i1 } %5, 1
  %6 = call i1 @llvm.expect.i1(i1 %_7.1, i1 false)
  br i1 %6, label %panic1, label %bb4

panic:                                            ; preds = %bb2
; call core::panicking::panic
  call void @_ZN4core9panicking5panic17h50b51d19800453c0E ...

bb4:                                              ; preds = %bb3
  store i32 %_7.0, i32* %n, align 4
  br label %bb1

panic1:                                           ; preds = %bb3
; call core::panicking::panic
  call void @_ZN4core9panicking5panic17h50b51d19800453c0E  ...

Recall that as an argument, factorial takes mutable u32 value, which in IR is defined as a unnamed temporary %0. While function square's definition takes named variable %n as an argument, just like in a source code. This is because square never modifies its value, while factorial requires it to be mutable, and later makes argument's copy inside a function's scope. At the start of the function two named variables are defined %n and %acc. Each of them gets the allocated (with alloca call) 32 bits of memory with data alignment of 4 bytes. You can read more about memory alignment here.

After allocation, store instruction stores content laying in %0 temporary in the address of %n. In the address of %acc it stores constant value 1. Finally, it jumps to the entry point of a while loop. The bb1 label marks entry into the while condition. IR loads value stored at the address of %n into temporary %_3 and makes comparison between it and constant value 0. icmp checks if value stored at %_3 is unsigned greater than (ugt) 0 and assigns result to another temporary %_2. After that, it evaluates contents of %_2. If it's true, branch jumps to the label %bb2 if false - to label %bb5.

The bb5 label is marks the exit block of the while loop. Here it loads the value from the address of %acc into temporary %1 and returns it from the function. The label bb2 is the entry into the body of a while loop. The body of a while loop is split in two halves. First one, responsible for the multiplication operation (bb2 label) and the second one responsible for decrementing n, or subtraction operation. The operation n = n - 1 is done by calling another intrinsic function for unsigned subtraction. The rest are the same operations as we saw in square function (Fig 4-a).

Figure 4-a. Control Flow Graph & Basic Blocks

You'd noticed the SSA form in action here. For every assignment instruction, instead of reassigning value back to n and acc, as it's defined in the source code, IR introduces new unnamed temporary for each instruction. The numbering of unnamed temporaries is incremented within a function at each instance when they are spawned, starting from 0.

LLVM IR supports Two's Complement of binary numbers. It has data types for integers like i8, i16, i32, i64 and floats f16, f32, etc. which are referred es operands. If you see an asterisk symbol after integer type that means we are dealing with a pointer (example: i32*). Value can also be constant. Each instruction also has its types, for example, arithmetic operators, binary comparison, data stores, and loads. There is much more of what IR performs and you can find the full list on the link at the end of this section.

The class hierarchy of LLVM is little bit complicated. The base object is what's called Value, that is used to represent a SSA register. All the other classes inherit from it. Then comes User class followed by Instruction, Operator, Constant classes and so on (Fig. 4-b). Here is the full tree of class inheritance inside LLVM.

Figure 4-b. LLVM Class Hierarchy

LLVM Language has many high-level structures, types, constants, functions, codegen instructions, etc. If you are interested learning more about it you can scroll through the reference manual.

Summary

As we reviewed in this article LLVM IR has many use-cases and allows us to analyze and optimize source code through its passes. Knowing IR language itself will help us to write our passes and build projects around it for debugging, testing, optimizing. Currently, LLVM IR doesn't have Rust API. It's mainly used through the C++ library. However, some user-created repos are available on crates.io. There is a Rust binding to LLVM's C API - llvm-sys and two other, more Rusty APIs that are using LLVM: inkwell and llvm-ir. And finally, if you want to learn how to write a LLVM pass you should start here.

Getting Started with Systems Programming with Rust (Part 2)

Beka Modebadze — Thu, 19 Aug 2021 06:39:14 +0000

Building a Mini-Shell

In the introductory Part 1, we discussed what system processes are, how to spawn them, and how to pass commands and execute them. If you want to review this material first you can click here.

In this section we’ll learn:

- What are system signals and how to handle them.

- What are stdout, stdin, and stderr, and how to use them efficiently.

- Writing to stdout and reading from stdin, instead of printing and what’s the advantage of doing so.

- Managing parent and child processes and their execution order.

To demonstrate the above-listed topics in practice, we’ll be building a UNIX mini-shell, which will be able to take commands from a user in the terminal and execute them. The program will also handle some invalid commands and deal with stuck programs gracefully.

stdin, stdout, and stderr

Probably you are familiar with what streams are in computing, if not just like water streams, it refers to the flow of data from source to an endpoint. Streams allow connecting commands, processes, files, etc. There are three special streams:

- stdin (Standard Input): which takes text as an input.

- stdout (Standard Output): stores text output in the stdout stream.

- stderr (Standard Error): When an error occurs during a stream the error message is stored in this stream.

The Linux system is file-oriented. This means nearly all streams are treated as files, and those streams are processed based on the unique identifier code that each file type has. For stdio (collection of standard output, input, and error) assigned values are 0 for stdin, 1 for stdout, and 2 for stderr. If we want to read a stream of text from the command line, in C we use the function read() and supply code 0 as one of the arguments for stdin (Figure 1-a).

Figure 1-a. Stdin Stdout & Stderr diagram

Reading and writing from stdio is a little bit different in Rust, but fundamentals remain the same. To better demonstrate their use we’ll start writing code for our mini-shell program. Initially, we’ll create a loop that will be asking the user to type in a command that the system will execute. The first two functionalities we need to create are writing to stdout and reading from stdin.

use std::io::{self, Write};

/// flushes text buffer to the stdout
fn write_to_stdout(text: &str) -> io::Result<()> {
    io::stdout().write(text.as_ref())?;
    io::stdout().flush()?; // flush to the terminal
    Ok(())
}

We’ll use a standard io> module to write to the terminal. Instead of passing String by copy, the function write_to_stdout() takes a reference to a string slice as an argument. The str is different from String. It’s what Rust refers to as a slice, is a reference to a part of a String. If you want to better understand the difference between those two, I’d recommend reading chapter 4 from Rust's official book.

The write_to_stdout() function returns Result object which can be Ok or Err. As those names suggest if everything goes as planned we’ll return Ok otherwise Err is returned. This procedure is so common in Rust that to return Err we have a special symbol ? at the end of the function call that can end up in error.

Inside the function, we call a write() function that fills the text buffer of the stdout and then we flush text on the screen. Inside write() we usa as_ref() method which converts string slice into an ASCII byte literal, as this is what the above-mentioned function expects as an argument.

Next, we need to build a function that will read the user inputted command, and process it. For this, we’ll write a custom function get_user_command() that returns String.

/// fetch the user inputted command from terminal
fn get_user_command() -> String {
    let mut input = String::new();
    io::stdin().read_line(&mut input).unwrap(); // not receommended

    if input.ends_with('\n') {
        input.pop(); // remove last char
    }

    input
}

The function reads a full line from the terminal and copies a value into an input variable. The read_line() takes mutable reference of the input String variable, dereferences inside the function call, writes user-supplied command, and returns Result. When we read a line from stdin it’s EOL (end of line) terminated, which includes the \n control character at the end and we need to get rid of it before returning input.

Finally, we glue our input and output functions together with our mini-shell program.

use std::io::{self, Write};

fn main() {
    loop { run_shell(); }
}

fn run_shell() {
    let shellname = "ghost# ";
    match = write_to_stdout(&shellname) {
        Ok(v) => v,
        Err(e) => {
            eprintln!("Unable to write to stdout : {}", e);
            process::exit(1);
        },
    }

    let cmnd = get_user_command();
    if let Err(_) = process::Command::new(&cmnd).status() {
        eprintln!("{}: command not found!", &cmd);
    }
}

In our main() function we run a loop that prints the shell name to the terminal screen and waits for the user to input the command. The run_shell() writes to stdout using previously defined function by us and handles an error if it occurs during printing. If something goes wrong it notifies a user about it and exits the program with error code 1 (Unsuccessful compilation).

Next, it reads the user-supplied command and passes that command to a newly created process. Then we check the status of the command execution, and if the command was unsuccessful we notify a user that the “command not found” and instead of exiting here, we return to the loop of prompting the user for an input.

Run the program with cargo run and we should see output similar to this:

A good question to ask here is why we use to read and write functions instead of simply printing to the screen. The reason behind this is that directives like read and write are what’s called Async-Signal Safe functions, while C's printf is not. They can be safely called within a signal handler (which we’ll review next).

The functions that are Async-Signal Safe are guaranteed not to be interrupted or interfered with when some signal is sent. For example, if we are in the middle of println!() call and a signal occurs whose handler itself calls println!() can result in undefined behavior. Because in this case, the output of the two println!() statements would be intertwined.

System Signals

To improve our mini-shell we have to handle system signals. Signals in the UNIX environment are sort of notifications that are sent by an operating system to a process to notify about a certain event, which usually ends up interrupting the process. Each signal has a unique name and integer value assigned to it. You can check the full list of signals of your system by typing kill -l in your terminal.

By default, each signal has its handler defined which is a function that is called when a certain signal arrives. We can modify the handling of those signals (which we’ll do for our mini-shell project). However, some of the signal handlers can’t be modified.

For our project will take a look at four following signals:

SIGINT

Ctrl+C

INT

SIGINT

SIGQUIT

Ctrl+\

QUIT

SIGALRM

SIGKILL

Now, it’s time to check how we’ll be handling the above-listed signals in Rust (except SIGKILL for which we can’t change default behavior). For example, if you run cat command in the Linux terminal without a file argument it will get stuck in an infinite loop. When this happens in our mini-shell we’ll rewire the SIGINT signal so it will forward the interrupt signal to the child process. This will only terminate the running loop but will keep our shell program running.

use signal_hook::{iterator, consts::{SIGINT};
use std::{process, thread, error::Error};
use nix::sys::signal::{self, Signal};

/// Registers UNIX system signals
fn register_signal_handlers() -> Result<(), Box<dyn Error>>  {
    let mut signals = iterator::Signals::new(&[SIGINT])?;

    // signal execution is forwarded to the child process
    thread::spawn(move || {
        for sig in signals.forever() {
            match sig {
                SIGINT => assert_ne!(0, sig), // assert that the signal is sent
                _ => continue,
            }
        }
    });

    Ok(())
}

First, we create an iterator of signals which stores a vector of signal references. Here we indicate which signals are expected to be handled. Next, we need to forward the signal to the child process, the one which is actively running, and perform desired behavior on it. This is done by spawning a new thread that returns a JoinHandler.

This handler will detach a child process after being dropped. This means when SIGINT arrives at the child's process, that process will be separated from the parent and it will only interrupt whatever the child process is doing, while the parent process will continue running. If there is no child process in execution it will do nothing.

We use forever() function on signals iterator which returns an infinite loop over arriving signals. As soon as the signal arrives it will be evaluated with a match-case and if it matches SIGINT it will assert that signal was sent successfully. For any other signal, the iterator will continue to wait for the next signal.

Since we rewired the SIGINT signal to only handle child processes, what if we want to exit the program completely? We’ll handle a different signal and let it print “Goodbye” to the stdout and exit graciously. For this one, we’ll use the SIGQUIT signal, which can be sent from the keyboard by pressing Ctrl + \.


use signal_hook::consts::SIGQUIT;

// .. previous function introduction and matching ..

        SIGQUIT => {
            write_to_stdout("Goodbye!\n").unwrap();
            process::exit(0);
        },

// .. rest of the function ..

When the SIGQUIT signal is called it’s matched in our iterator and this calls our write_to_stdout() function. Then program exits with code 0, which in Linux stands for a successful compilation. Notice we are importing SIGNAL consts from signal_hook library, which is a library for easier Unix signal handling.

Finally, we’ll add a small feature to our program. The user will supply an integer at the program's start. This number will be used as a countdown for the program’s execution time. For example, if a user supplies 5, this will invoke alarm(5) when the child process is started. If a function isn’t complete when the countdown ends, our manually defined SIGALRM signal will kill it and return the program to the initial state.

use signal_hook::consts::SIGALRM;
use nix::sys::signal::{self, Signal};
use nix::unistd::{alarm, Pid};

/// alarm will be called from `execute_shell(timeout: u32)`
/// after function collects user input it calls `alarm::set(timeout)`

// .. beginning of the register_signal_handlers function ..

        SIGALRM => {
            write_to_stdout("This's taking too long...\n").unwrap();
            // when alarm goes off it kills child process
            signal::kill(Pid::from_raw(0), Signal::SIGINT).unwrap()
        },

// .. rest of the function ..

When SIGALRM is matched, first, it will write to the stdout, and next, it does a very interesting thing. It will use the signal::kill() function to send the SIGINT signal on a process it operates. But since the same function handles SIGINT by forwarding it to a child process it will only kill the child process and return back to the main program of running mini-shell. Full function:

use signal_hook::{iterator, consts::{SIGINT, SIGALRM, SIGQUIT}};
use std::{process, thread, error::Error};
use nix::sys::signal::{self, Signal};
use nix::unistd::{alarm, Pid};

/// Register UNIX system signals
fn register_signal_handlers() -> Result<(), Box<dyn Error>>  {
    let mut signals = iterator::Signals::new(&[SIGINT, SIGALRM, SIGQUIT])?;

    // signal execution is forwarded to the child process
    thread::spawn(move || {
        for sig in signals.forever() {
            match sig {
                SIGALRM => {
                    write_to_stdout("This's taking too long...\n").unwrap();
                    // when alarm goes off it kills child process
                    signal::kill(Pid::from_raw(0), Signal::SIGINT).unwrap()
                },
                SIGQUIT => {
                    write_to_stdout("Good bye!\n").unwrap(); // not safe
                    process::exit(0);
                },
                SIGINT => assert_ne!(0, sig), // assert that the signal is sent
                _ => continue,
            }
        }
    });

    Ok(())
}

These should be an expected outcome if you run our mini-shell through the terminal:

You can find a full code of the mini-shell, which includes some additional features besides covered here, in this GitHub repository.

Summary

Today we learned what are stdin, stdout, and stderr, and how to use them properly. We looked at the common UNIX system signals and manually handled three of them to fit the needs of our mini-shell program. The combined knowledge from Part 1 allowed us to build a program that executes system commands and handles system signals safely and fast thanks to the Rust language.

In the upcoming parts, we’ll take a look at communicating between processes between pipes and review concurrency. We’ll demonstrate why Rust can be the best choice for this.

...

Getting Started with Systems Programming with Rust (Part 1)

Beka Modebadze — Fri, 13 Aug 2021 13:25:35 +0000

You can find original post on my personal blog.

A modern computer is a very complex creation that evolved into the current state through decades of research and development. Sometimes it appears to be like black magic. There’s no magic in it, just science. However, some of the minds like Alan Turing, Charles Babbage, Ada Lovelace, John von Neumann, and many others are magical, as they made this possible.

Ok, that’s enough of introductions and let us dive into the fundamentals of systems programming. In this part we’ll learn:

- What is the process?

- How are they created and executed?

- Look at some code examples in Rust and compare them to C.

Before diving into code we’ll start to build up from the lowest level of the main components of the operating systems. As shown in Figure 1-a the lowest level of any computer is Hardware, next comes the Kernel mode which runs on bare metal. This is where the operating system, like Linux, is located.

Figure 1-a.

On top of the Kernel mode, we have a User-mode. For a user to be able to interact with the kernel AND use other higher-level software, like web browser, E-mail reader, etc. it requires a user interface program. This can be a window, Graphical User Interface, or it can be a shell which is a command interpreted that is used to read commands from a terminal and execute them

Processes: Parent and Child

The main concept in all operating systems is a process. A process is basically a running program. You can think of it as a drawer that contains all the information about that particular program. Some processes start running at the start of the computer, some run in the background, and some are called and interacted by the user, through the shell, for example.

All the processes have an id. The very first process is initiated, when the system is booted. This process has an id of 1 and is called init. After that, init will call other processes and so on. When we type a command in a shell for the OS to execute, the system should create a new process that will run the compiler. When the process has finished compiling, it will make a system call to terminate itself.

In UNIX systems every new process is a child process of some parent process. Process creation is done by cloning a parent process, which is referred to as forking (Figure 1-b). Each process has one parent but can have multiple child processes. The structure of the processes resembles a tree, where init is the root, meaning it’s at the top of the hierarchy.

After the process’s creation, the parent and the child processes are the same, except the parent will have some arbitrary ID number, and the child process will have an ID equal to 0. Next, the system substitutes the child process’s execution with a new program. When the process is done fulfilling its purpose, it’s terminated and exited normally (voluntary). The process can also be exited due to an error or killed by another process (involuntary).

Figure 1-b.

The system also keeps track of all the processes, maintaining their data in what’s called a processes table. It holds information like process id, process owner, process priority, environment variables for each process, the parent process. In addition to that, it also holds the info in what state a particular process is. Each process can be in one of the following four states:

RUNNABLE — The process is running / actively using the CPU.

SLEEPING — The process is runnable, but is waiting for another process to stop/finish first.

STOPPED — This state indicates that the process has been suspended for further proceeding. It can be restarted to run again by a signal.

ZOMBIE — The process is terminated when ‘system exit’ is called or someone else kills the process. However, the process has not been removed from the process table.

Often processes have to interact with each other and can change the state and go from Running to sleeping, then back to running (Figure 1-c). This is usually done by a SIGSTOP signal, which is issued by Ctrl + Z (We’ll review signals in-depth in upcoming parts). Same with the stopped process, its activity can be restarted. Except for the Zombie state, which once killed can’t be restarted or continued.

Figure 1-c.

C vs Rust

In C, which is an official Linux kernel programming language, process creation is done first by forking the new process and then explicitly asking a system to execute a new directive on a child process. If we don’t do that, both parent and child processes will be executing the same directive. Here is an example of executing ls command, which lists files of given directory:

#include stdio.h
#include sys/types.h
#include sys/wait.h

int main()
{
    pid_t pid;
    switch (pid = fork()) {
        case -1:
            perror("fork failed");
            break;
        case 0:
            printf("I'm child process and I will execute ls command");
            char *argv_list[] = {NULL};
            if (execv("ls", argv_list) == -1) {
                perror("Error in execve");
                exit(EXIT_FAILURE);
            }
            break;
        default:
            printf("I'm parent process and I'll just print this");
        }

    return 0;
}

As you can see we have to manage the processes manually and monitor if the execution was successful. Also, we have to handle errors. If we want a command to be executed only by a child we have to manually check if the current process is a child, which is done here by case 0. In Rust, the same can be achieved with a standard library’s process module:

use std::process::Command;

fn main() {
    let child = Command::new("ls")
                .env("PATH", "/bin")
                .output()
                .expect("failed to execute process");

    // if no error, program will continue..
}

Here Command::new()is a process builder which is responsible for spawning and handling a child process. Just like in a C code, we supply a command we want to execute, environmental variables, command argument, and call output method on it. The output will execute the command as a child process, waiting for it to finish, and returns the collected output.

Instead of output() we also have options to use either status() or spawn(). Each of these methods is responsible for forking a child process with subtle differences:

output()

Output

status()

ExitStatus

spawn()

Child

wait

kill

Here, env() is optional, as the Command is smart enough to look for the path of a /bin folder. Finally, all the error handling is done by expect(). It unwraps the result if Ok, meaning the program was executed successfully, or Err if something went wrong and will panic!. If you want your program not to terminate if Err encountered you can do something like this:


use std::process::Command;

main() {
    let user_input = get_user_input(); // custom function
    if let Err(_) = Command::new(&amp;user_input)
                            .envs("PATH", "/bin")
                            .status() {
        println!("{}: command not found!", &amp;cmd);
    }
    // the rest of the program...
}

Here status() is handier and calling it will return Ok if the legit command is supplied by the user and execute. But we are only interested in handling if the unavailable command was supplied. That’s why we only check if Err was returned, and if so print that “command was not found” into the terminal and continue the current program execution, instead of terminating.

Finally, the spawn() is used to manage the order of execution between several children and parent processes. It contains stdin stdout and stderr fields and has, familiar to C programmers, wait() , kill() and id() methods. We’ll look at this part of the processes in the next part and we’ll also see how Rust takes care of race conditions when two or more threads can access shared data and they try to change it at the same time.

Summary

In this introductory part, we reviewed what are processes, how they are created and compared Rust's implementation of the processes creation and command execution to C. We saw that Rust code not only is less prone to human errors but it’s less verbose and more concise. In the next parts, we’ll take a look at managing processes execution time and states, and handling system signals

5 Reasons Why You Should Start Using Rust for Personal Projects

Beka Modebadze — Tue, 10 Aug 2021 19:43:33 +0000

When one master's student at the University of Helsinki was not able to get his hands on one of the UNIX operating systems for his personal computer, he started a side project. He wanted to build a kernel that ran on his PC. Linus Torvalds' side-project as you may know was Linux, which is the most popular operating system in the world and currently runs approximately on 1 billion devices.

Steve Wozniak, the co-founder of Apple, was toying with computers in his basement when Jobs discovered and convinced him to make money off of his creations. These are just two famous stories. There are many more where the side-project started something interesting, something big, something game-changing, or at least resulted in a good job offer. In this post, I'll try to convince you why you should do side-projects and why you should do them with Rust.

Importance of Personal Projects

Personal side-projects convey three important values. First, it's the best way to learn new technologies, and tools, frameworks. The only way you can retain some knowledge from recently learned material is to do some projects. It allows you to experiment, test out ideas, and practice the implementation of those ideas. I personally came to a firm conclusion that I can't say that I understand technology if I haven't done a personal implementation of it.

Second, it's a form of signaling. Signaling is an important part of the successful job search and career advancement. If you were an economist probably you don't need further clarification on what signaling is. However, I assume the majority of you are not so I'll give a quick tour of the signaling part of the contract theory.

Signaling is the way how one party (namely agent) dispatches the information about itself to another acting party (namely principal). In the job market, this can be seen as an attempt by the potential candidate to showcase their ability to the potential employer. For example, your bachelor's degree (if you have one) is a form of signaling. It shows that for at least four years you worked hard, managed to pass the required class, and hopefully attained knowledge.

Side projects or portfolio projects are also a form of signaling. They convey a message to the potential hiring managers that you can show initiative. You can take ownership of the project and work on it independently. It also demonstrates that you have a genuine interest in a field and a desire to learn. Often students and people looking for their first developer roles are highly encouraged to work on personal projects.

Third, it's a great way to network and make interesting connections. I've personally developed relationships with several developers who have contributed to my project or I contributed to theirs. This is a meaningful connection, because it's voluntary and built on mutual interest. You choose with whom you want to work on a project or task, you can find people with the same interest within interest.

How Rust is Used by Developers

Understanding the benefits of side-projects brings us to the second point. What is the current state of Rust? I'll not tell you that learning Rust will get you a job, because that would be a lie. There aren't many (especially entry-level) software Engineer jobs asking for Rust. However, the way it's currently utilized couples perfectly with the above-written argument.

Recently JetBrains published the developer survey for 2020 about Rust programming language . It was asking why developers chose to use Rust, how they used Rust, what kind of projects they worked with Rust, and if they interact with other languages and other people. It's worth mention that big majority of developers (67%) use Rust for personal projects/hobbies and 80% of them have been using it for less than a year.

How Developers use Rust

I'm personally happy to see these numbers. Foremost because this is an organic programming language growth path. People start trying new things, building pet projects, get hooked, and then try to convince their employers to use those technologies, or even go and build their companies using those technologies.

The fact that the majority of developers have not been with Rust for more than a year also indicates that language is in an early stage and still needs to mature. Getting started with Rust now will give you a frontline seat for the senior roles when Big names will start looking for the experienced Rust developers. And believe me, the way language is progressing and gaining popularity that time is not that far away.

Rust's not only a systems programming language as usually it's advertised. Statistics of project types built with Rust also hint that it's a multipurpose programming language. Yes, it is prominently used for systems programming (56%) but the frequencies of its usage for Web (44%) and Network (32%) are not that far. People are even developing libraries for Machine Learning and building game engines. It's an illustrious community and there's a higher chance you'll find fellow tech enthusiasts to work on something exciting together.

Project Types developed with Rust

In summary, we see that the popularity of Rust is on the rise. Developers are experimenting with various libraries and the community is growing every day. Rust goes beyond being just a systems programming language as people are discovering the advantages of including Rust in various ways in their projects.

Now, Why Rust?

We examined how Rust is used and saw the multiple directions it's growing and gaining momentum. However, the question still stands. Why Rust? Why you should use Rust? What are eminent features that are alluring developers like a flower attracts bees?

Instead of just listing personal opinions I decided to ask more experienced Rust developers why they chose Rust and list personal opinions. The question I asked was simple: "What is your elevator pitch for Rust?". My question got a lot's of responses and stimulated some discussion on Rust's user forum. I handpicked the most interesting replies but if you want you can read through the whole feed here.

Rust Crab Ferris

To answer above asked questions I'm going to review following five arguments of why you should start using Rust for personal side-projects:

Zero-cost abstraction
Immutable and Private by default
Full Experience with Cargo and Rust Compiler
Safety first! no dangling pointers, no memory leaks, and no race conditions
Rust is not JAL (Just Another Language)

Zero-Cost Abstraction

You pay only for what you use. The runtime is based on what features you use for your program. What does this mean? For example, in Java or C#, every time you abstract code by introducing additional classes it adds overhead to your program. Because both languages have garbage collectors your extra layer of code needs to be cleaned after the program is done using it. This can significantly slow down your program. In Rust, high-level APIs will directly compile into machine code and can have as good performance as if you'd written lower-level code.

Immutable and Private by Default

When you define variables in Rust they are immutable by default. If you want the variable to be modifiable you need to explicitly state that by using mut keyword. The same goes for the data access modifiers. If you don't state that any field, function, struct, enum, or mod is public its access level is inherently limited to the local scope. Similar to what Java and C# does when you set class or function to private.

What's the advantage of this? - A reduction in human error. Popular philosophy about how to set access modifiers is to maximize data protection. For example, if you know a field or function shouldn't be used outside of the class where it's defined it should always be set to private. When data is being modified or accessed where it shouldn't this can cause major bugs and security issues. Private by default push developers to be more conscious of their program design choices and helps to faster detect bugs.

Cargo and Compiler

When you set up Rust, you not only get Rust the programming language, you get a full environment. Rust comes with cargo, a user-friendly package manager. Cargo gives ease of managing dependencies and setting up build configurations. With only a handful number of commands, you'll be able to create projects, run projects, test them, and even upload to the crates.io where other Rust libraries and packages reside.

Rust also comes with an amazing compiler. One of the first pieces of advice given to me when I started using Rust was not to fight the compiler. Instead, listen to it. Rust compiler utilizes LLVM's decades of optimization. However, besides that, it's very verbose and descriptive of what went wrong. It also suggests potential fixes and alternative approaches developers may consider to overcome given errors during compilation. If your code compiles it's highly likely that it will run without errors.

Safety First!

The core philosophy of the Rust language is to keep it safe without sacrificing performance. It may sound counterintuitive when you hear this first time (at least it was for me), but it's true. We already mentioned that Rust has no garbage collector. Instead, Rust uses what's called lifetimes. This not only allows code to run fast, but it also guarantees that no unused allocated memory lives in the program when its lifecycle is over. This exterminates the problems known to C developers like memory leaks and dangling pointers.

Rust handles concurrent and parallel program design problems fearlessly. As Chapter 16 of Rust's official Book says:

"By leveraging ownership and type checking, many concurrency errors are compile-time errors in Rust rather than runtime errors. Therefore, rather than making you spend lots of time trying to reproduce the exact circumstances under which a runtime concurrency bug occurs, incorrect code will refuse to compile and present an error explaining the problem."
If you want to learn more about how Rust solves this problem I'd suggest reading above mentioned Chapter 16: Fearless Concurrency

Rust isn't JAL (Just Another Language)

There are so many new programming languages getting born and getting hyped and then dying out namelessly. But not Rust. Graydon Hoare and the team at Mozilla gave much thought to the language design to solve many issues other popular languages have. This attracted lots of developers.

Thoughtful conversations, suggestions, and contributions bestowed the language's growth in the right direction. Rust's community is very welcoming and offers immense support to the newcomers. The Rust's Reddit, Discord channel, and Rust forum are amazing places to connect with other Rusteceans, ask for help, or seek advice. So I'll ask you:

DEV Community: Beka Modebadze

LLVM Infrastructure and Rust

What is LLVM Infrastructure

How LLVM Works

LLVM's Program Structure

LLVM and Rustc

Summary

Getting Started with Systems Programming with Rust (Part 2)

Building a Mini-Shell

stdin, stdout, and stderr

System Signals

Summary

Getting Started with Systems Programming with Rust (Part 1)

Processes: Parent and Child

C vs Rust

Summary

5 Reasons Why You Should Start Using Rust for Personal Projects

Importance of Personal Projects

How Rust is Used by Developers

Now, Why Rust?

Zero-Cost Abstraction

Immutable and Private by Default

Cargo and Compiler

Safety First!

Rust isn't JAL (Just Another Language)

For the next side-project try Rust!