Bfh-sts: Created page with "= 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..."

2025-10-20T13:43:08Z

Created page with "= 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..."

New page

= 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.

[[Category: Development Process]]

Workflow in Practice: Edit–Assemble–Link–Run–Debug - Revision history