Top 25 GDB (GNU Debugger) Interview Questions and Answers

As a software developer having strong debugging skills is essential for writing high-quality code. One of the most widely used debuggers is GDB – the GNU Debugger. With its robust feature set and cross-platform capabilities GDB has become a must-have tool for C, C++, and other programmers.

If you have an upcoming interview where GDB expertise could be tested it’s crucial to go in fully prepared. To help you get interview-ready I’ve put together this comprehensive guide covering the top 25 GDB interview questions and example answers. Read on to brush up on your debugging knowledge!

1. What is GDB and why is it useful for developers?

GDB stands for GNU Debugger. It’s an open-source, command-line debugging tool used to analyze programs written in languages like C, C++, Rust, Go and more.

Here are some key reasons why GDB is invaluable for developers:

• Allows inspecting program state during execution or after a crash by setting breakpoints, stepping through code line-by-line, and examining variables.

• Can catch errors and exceptions, providing insights into why they occurred.

• Changes variable values on-the-fly for testing scenarios.

• Alters control flow arbitrarily using commands.

• Supports reverse debugging to go back in time and understand code flow.

• Portable across platforms like Linux, Windows, Mac.

By leveraging these features, developers can comprehend code behavior, identify bugs faster, and improve overall quality.

2. How do you invoke GDB to debug a program?

To invoke GDB for debugging, first compile your code with the -g flag to include debugging symbols. Then run:

gdb program_name

This will start GDB and load the program’s symbol information. You can then utilize various commands like run, break, print within GDB to control execution and inspect state.

For debugging a running process, attach GDB to its PID:

gdb -p <PID>

For core dumps, initiate GDB with both program name and core file:

gdb program_name core

3. How are breakpoints useful when debugging with GDB?

Breakpoints are an extremely useful GDB feature that pauses execution at specific lines or functions. This lets you:

• Halt at critical areas to check program state.

• Isolate bugs by stopping before/after their occurrence.

• Analyze step-by-step flow around points of interest.

• Modify variables before resuming, enabling complete control.

Breakpoints help focus debugging efforts instead of blind executions or scattered print statements. Their strategic use can save significant time and effort.

4. What are the ways to set a breakpoint with GDB?

Breakpoints can be set using multiple approaches:

• Line number: break <line_no>

• Function name: break function_name

• Address: break *address

• Conditionally: break <loc> if <condition> (halt only if condition met)

• Watchpoint (on variable modification): watch var_name

After setting any breakpoint, use info breakpoints to list them all. Use delete to remove breakpoints when done.

5. How do you resume a program’s execution in GDB after pausing it?

After hitting a breakpoint and pausing execution, you can resume the program using:

• continue – Resume and continue until next breakpoint

• step – Execute next line, stepping into functions

• next – Execute next line, stepping over functions

• finish – Run until current function returns

So step goes deeper while next advances without descending inside functions. Use these commands based on the area of code you want to traverse.

6. How can you print variable values when paused in GDB?

When execution is paused, key commands for printing variable values are:

• print <var_name> – Print value of a specific variable

• print /x <var> – Hexadecimal format

• print /t <var> – Binary format

• print *ptr – Dereference pointer

• print {int}0x1234 – Print value stored at address

• print/x array[0]@10 – Print 10 elements of array

So prefix format specifiers like /x and suffixes like @10 help customize output.

7. What are some ways to examine the call stack when debugging in GDB?

Key options for examining call stack state:

• backtrace (or bt) – Display current call stack

• frame N – Move to frame N in the stack

• up/down – Move up/down the stack

• info frame – Details of current frame

• info locals – Local variables of current frame

• info args – Arguments passed to current function

The call stack is immensely useful for tracing execution flow and identifying issues. Make sure to inspect it closely around crash points.

8. How can you access previous values of variables in GDB?

GDB has a value history feature that records previous values of expressions and variables during debugging.

To examine value history:

• show values <N> – Display N recent values

• show values <var> – Show history of var

• show values – Display value history of all active variables

This history allows “time-traveling” – you can inspect variables’ past values to understand when/why they changed.

9. What is reverse debugging, and how is it helpful?

Reverse debugging is a powerful GDB capability that lets you step backward in the program’s execution history. Commands include:

• reverse-step – Reverse execute previous line

• reverse-next – Reverse step over functions

• reverse-continue – Full reverse execution

This helps in situations where you need to retrace the steps leading to a bug or crash. Without modifying code, you can literally go back in time and observe the sequence of events.

10. How can you debug C++ programs with templates in GDB?

Debugging templated C++ code requires enabling pretty-printing of STL data structures. This is done via:

set print pretty on

Now you can inspect STL containers, use print on template types, and GDB will format output readably.

For overloaded functions, breakpoints need full mangled names:

break overloaded_func<type>(...)

11. What are some best practices for effective debugging in GDB?

Some key best practices include:

• Always compile with -g flag for debug info.

• Master essential commands like print, break, next, step, backtrace.

• Inspect variables frequently for unexpected values.

• Leverage reverse debugging for hard-to-reproduce bugs.

• Use pretty-printing for template variables and complex data structures.

• Double-check logic around loops, pointers, function calls.

• Enable warnings and rigorously test edge cases.

• Keep notes on observations for later analysis.

• Understand GDB documentation and lookup unfamiliar concepts.

12. How can you get assembly output in GDB?

We can view the corresponding assembly instructions in GDB using:

disassemble <function>

This intermixes the source code and assembly for the specified function.

To get raw assembly:

set disassembly-flavor intel  disassemble /m <function>

The /m flag omits source code mixing.

Examining the assembly code can provide insights into lower-level operations, calling conventions, optimizations etc.

13. What are some advantages of using GDB over printf debugging?

Some key advantages GDB provides over printf debugging:

• Can debug without modifying source code.

• Inspect variables easily without inserting printfs.

• Pause and resume execution precisely with breakpoints.

• Examine state of entire program, not just prints.

• Zero overhead when not debugging unlike printfs.

• Reverse execute to retrace steps.

• Portable debugging across environments.

• Automate debugging workflows with macros.

Overall, GDB enables more disciplined, flexible and efficient debugging versus printfs.

14. How can you get help for GDB commands and their usage?

GDB provides multiple options for getting help:

• help – List categories of commands

• help <command> – Description and usage of a command

• apropos <text> – Search commands related to text

• document <command> – Detailed help for command

• set documentation – Verbose mode for help content

The GDB manual and online