Debugging

Today's Agenda

• Debuggers
• Implementation of Debugger

What is a Debugger?

What is a Debugger?

A debugger is a software tool used by programmers to inspect and manipulate the execution of a computer program. It helps in identifying and fixing bugs or errors in the code.

The primary purpose of a debugger is to allow programmers to see what is happening 'inside' a program while it executes or what the program was doing at the moment it crashed.

Machine-level Debuggers

Machine-level debuggers enable debugging at the low-level assembly or machine code, offering granular control and deep insights into the program's execution at the hardware level.

Source-level Debuggers

Source-level debuggers allow developers to debug programs at the high-level source code level, providing an intuitive and user-friendly interface for code inspection and debugging.

Standalone Debuggers

Standalone debuggers are separate applications dedicated to debugging. They are often more specialized and can be used independently of any specific IDE.

Integrated Debuggers

Integrated debuggers are built into IDEs, offering a seamless debugging experience within the development environment, with features tailored to the IDE's supported languages and frameworks.

Multi-threaded Application Debugging

Debugging multi-threaded applications involves unique challenges due to the concurrent execution of threads, making it harder to predict and replicate specific states and issues.

Remote Debugging

Remote debugging refers to the process of debugging a program running on a different system (server, virtual machine, or container) from the debugger itself, allowing developers to diagnose issues in different environments.

REPL

A Read-Eval-Print Loop (REPL) is a simple, interactive computer programming environment. It allows for the execution of user inputs and returns the results to the user. REPLs enable piecewise execution of programs.

In a REPL environment, user inputs are read, evaluated (executed), and the results of this evaluation are then printed out. This loop provides an interactive space for testing and debugging code.

Evolution of Debuggers

1950s: Simple Logging Methods

In the 1950s, debugging was a rudimentary process, largely based on the use of print statements and manual logging. Developers relied on inserting print commands in their code to output variable values and program states to a console or log file. This method, although primitive, was crucial for early software development, allowing programmers to track the flow of execution and understand where errors might be occurring.

1970s: Interactive Debuggers

The 1970s introduced a significant advancement in debugging technology with the emergence of interactive debuggers. These tools allowed developers to interact with running programs, setting breakpoints, and inspecting program state in real-time. This innovation marked a departure from static logging methods, providing a more dynamic and efficient approach to troubleshooting code.

1990s: Integrated Debuggers

The 1990s saw the integration of debuggers into Integrated Development Environments (IDEs), significantly boosting developer productivity. This integration brought debugging tools directly into the software development workflow, offering a seamless experience. Features like graphical interfaces, source code highlighting, and context-aware debugging became commonplace, drastically simplifying the debugging process.

2000s Milestones

Debugging took another major stride in the 2000s with the introduction of advanced features like remote debugging and support for multi-threaded applications. Remote debugging allowed developers to diagnose issues in software running on different machines or environments, while multi-threading support was crucial for debugging more complex, performance-oriented applications.

Features

Breakpoints

Breakpoints are fundamental to debugging, allowing developers to pause program execution at specific points. They enable close examination of the state and behavior of the program at critical moments.

• Conditional Breakpoints: Trigger based on specific conditions.
• Line Breakpoints: Pause execution at a particular line in the code.
• Function Breakpoints: Activate when a certain function is called.
• Exception Breakpoints: Activate when a certain exception is thrown.

Stepping Through Code

This feature allows developers to execute code one line or instruction at a time. It's crucial for understanding the flow of execution and pinpointing where things go wrong.

• Step Over: Executes the next line of code, skipping functions.
• Step Into: Moves into functions or methods for a deeper look.
• Step Out: Exits the current function and returns to the caller.

Call Stack and Variables Inspection

The call stack is a record of active function calls in the program, showing which functions are running, where they were called from, and the state of their local variables. Inspecting the call stack helps in tracing the path of execution and understanding program flow.

Inspecting the call stack is particularly useful for diagnosing errors and understanding complex execution flows, especially in the case of nested function calls or recursive algorithms.

Inspecting variables is a key feature allowing developers to view and analyze the current state of variables at any point during program execution.

Most debuggers provide a watch window or similar tools to monitor the values of variables, helping developers understand how data changes over the course of execution.

Modifying Program State

Debuggers often allow for the modification of the program state, including changing variable values, to test different scenarios and understand the impact of such changes.

This feature is particularly useful for testing how different inputs affect program behavior without the need to stop and restart the program.

Expression Evaluation and REPL

Expression evaluation in debuggers allows developers to execute code snippets or evaluate expressions on the fly. This is useful for testing hypotheses about code behavior or inspecting values without modifying the source code.

Hot Reloading

Hot reloading refers to the ability of a debugger to apply changes in the code on the fly without needing to restart the application. This feature greatly enhances the development workflow by allowing immediate feedback on code modifications.

Hot reloading saves time and improves productivity by reducing the need for repetitive restarts and recompilations. It enables a more interactive and responsive development experience.

Implementation

Debugger Symbols

Debugger symbols are markers or labels added to software programs during the development process. They are used to establish a link between compiled binary code and the source code. They include information like variable and function names, line numbers, and file names, which are essential for debugging.

How do Breakpoints work?

Hardware breakpoints are implemented at the chipset level. They use comparators to match the instruction being executed with a preset instruction in a peripheral register. When a match occurs, a debug event is triggered, halting the processor or generating an exception. The number of hardware breakpoints is typically limited due to hardware constraints.

Software breakpoints are implemented by the debugger itself. They function by modifying the code to insert a breakpoint instruction or an instruction that causes a fault, thereby triggering a debug event. Unlike hardware breakpoints, software breakpoints can be virtually unlimited, although they face challenges like unpatchability of certain code regions (e.g., Read-Only Memory) and potential code corruption if the debugger crashes.

Software breakpoints in some systems (like x86 architecture) use software interrupts, or 'traps,' to implement breakpoints. The `int 3` instruction in x86 is an example, causing the operating system to stop the process and send a signal, typically `SIGTRAP`, to the debugger.

How does Stepping work?

Historically, instruction stepping involved stopping the processor clock and manually advancing it one cycle at a time. This required a control to stop the clock, a second control to manually advance the clock, and a means of recording the state of the processor after each cycle.

In modern processors, similar functionality to manual stepping is achieved via a trap flag. This flag, when enabled, instructs the processor to stop after each instruction, functioning similarly to a breakpoint.

Instead of using a physical stop button, modern debuggers employ breakpoints or a 'Pause' request. The debugger might also use system calls like `ptrace` on Linux to control the execution of a process, stopping it at specific points or after each instruction using signals like `SIGTRAP`.

How does Call Stack Inspection works

When a program stops at a breakpoint, the debugger provides information about the current state, including the current function and its callers. This is achieved by tracing function calls and maintaining a record of active function calls in the program. This function records the current state of the program, including the call stack, enabling the inspection of the sequence of function calls.

How does Expression Evaluator Work

Evaluating an expression involves a complex interplay among the debug engine (DE), the symbol provider (SP), the binder object, and the expression evaluator (EE). The EE takes an expression from the DE in the form of a string and evaluates it using various interfaces.

The EE uses the binder object, provided by the DE, to get the value of symbols and objects in the program.

Some debuggers, like Visual Studio, employ debugger intrinsic functions that allow the evaluation of certain functions without altering the application state. These intrinsic functions are safe to execute and can be used in all expressions.

Conclusion

Next: Advanced Features

Delve into the features of IDEs that offer intelligent search, effortless code navigation, code refactorings and automated code completion to boost coding efficiency.

Questions & Answers

Thank you for your attention!

I'm now open to any questions you might have.