Workflow in Practice: Edit–Assemble–Link–Run–Debug

Workflow in Practice: Edit–Assemble–Link–Run–Debug

This page summarizes the entire development process for assembly programs, showing how editing, assembling, linking, running, and debugging fit together.

The complete workflow

A typical software development process in low-level programming consists of five main phases:

1. **Editing** – Writing and commenting the source code. 2. **Assembling** – Translating the human-readable source into machine code (object files). 3. **Linking** – Combining all object files into one executable. 4. **Running** – Executing the program to test functionality. 5. **Debugging** – Finding and fixing errors or logic issues.

1. Editing

• Write code in a text editor of your choice (e.g., VS Code, nano, vim).
• Save files with the `.asm` extension.
• Use comments generously to document each instruction and purpose.

Good commenting is crucial. Poorly documented assembly code quickly becomes unreadable and unmaintainable.

2. Assembling

Use NASM or another assembler to translate your code into an object file.

Example: ```

nasm -f elf64 -g -F dwarf eatsyscall64.asm -o eatsyscall64.o

```

Common options:

• `-f elf64`: output format for 64-bit Linux.
• `-g`: include debug information.
• `-F dwarf`: specify DWARF debug format.
• `-o file.o`: output file name.

If you get errors or warnings, read them carefully and correct your source before proceeding.

3. Linking

Use `ld` (the GNU linker) to link one or more object files into a runnable executable.

Example: ```

ld -o eatsyscall64 eatsyscall64.o

```

The linker resolves addresses, combines code and data sections, and creates an ELF executable ready for execution.

4. Running

Run the resulting program directly from the shell: ```

./eatsyscall64

``` If everything worked, it should print: ```

Eat at Joe’s!

```

If the program crashes, check for missing system calls, register misuse, or incorrect data lengths.

5. Debugging

If the program does not behave as expected, use a debugger such as gdb.

Example: ```

gdb eatsyscall64 (gdb) break _start (gdb) run (gdb) step (gdb) info registers

```

With gdb you can execute one instruction at a time, inspect registers and memory, and verify that the program behaves as intended.

Automating the process

To avoid repeating the same commands, use a makefile: ```

make make clean

``` This ensures consistent, automated builds and reduces human error.

Summary

The full cycle can be summarized as:

```

Edit → Assemble → Link → Run → Debug → Repeat

```

Following this workflow ensures a structured and reliable development process, even when working close to the hardware.