Build & Debug Basics: Warnings, Errors, gdb Intro

From MediaWiki
Jump to navigation Jump to search

Build & Debug Basics: Warnings, Errors, gdb Intro

This page explains how to handle warnings and errors during assembly and linking, and introduces the concept of debugging.

Assembling and linking workflow

Typical workflow when writing assembly programs: 1. Edit and comment the source code (e.g. eatsyscall64.asm). 2. Assemble the source to produce an object file (`.o`). 3. Link object files to create an executable. 4. Run and test the executable.

Each step may produce messages that must be read carefully.

Warnings and errors

When assembling, NASM or another assembler may output warnings and errors.

  • **Errors** indicate code that cannot be assembled.
 * Example: misspelled instruction, missing label, or syntax error.  
 * The assembler stops producing output.
  • **Warnings** indicate potential problems.
 * Example: unused variables, mismatched data size, or deprecated syntax.  
 * Even if the program builds, warnings may point to logic errors.

Do not ignore warnings. They often reveal subtle issues that can cause unpredictable behavior at runtime.

Assembling example

```

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

```

  • `-f elf64`: output format for 64-bit Linux.
  • `-g`: include debugging symbols.
  • `-F dwarf`: specify DWARF format for use with gdb.
  • `-o eatsyscall64.o`: output file name.

If there are warnings, inspect the lines mentioned in the message and fix them.

Linking example

```

$ ld -o eatsyscall64 eatsyscall64.o

```

  • `ld`: GNU linker.
  • `-o eatsyscall64`: output executable name.
  • `eatsyscall64.o`: input object file.

If linking fails, the most common causes are:

  • Missing object files.
  • Unresolved external symbols.
  • Incorrect calling conventions or symbol names.

Always read the full error message to identify which symbol or file caused the problem.

Debugging

Debugging is the process of finding and removing errors (bugs) from a program. Even experienced programmers introduce bugs—industry averages are 15–50 errors per 1000 lines of code.

A debugger lets you:

  • Execute code step by step.
  • Inspect registers, memory, and stack.
  • Pause execution and set breakpoints.
  • Modify program state to test hypotheses.

The GNU Debugger (gdb)

gdb is the standard debugger for Linux systems. It can be used with programs compiled or assembled with debug information (`-g -F dwarf`).

Example (will be discussed in detail in ASM07): ```

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

```

This lets you watch how each instruction changes the CPU’s state.

Key takeaways

  • Treat warnings as valuable hints, not minor inconveniences.
  • Understand the difference between assembling, linking, and running.
  • Learn to use a debugger early—it’s an essential development tool.
Retrieved from "https://bsccs.stoney-wiki.com/w/index.php?title=Build_%26_Debug_Basics:_Warnings,_Errors,_gdb_Intro&oldid=84"