Last Updated: 2023-02-23 Thu 08:41

CSCI 2021 Lab06: GDB Basics

CODE DISTRIBUTION: lab06-code.zip

VIDEO DEMO: Available courtesy of TA Dat

CHANGELOG: Empty

1 Rationale

Debuggers are an essential tool for any serious coder. They provide the ability to stop a program at any point and inspect its state by examining variables, traversing memory, and showing stack traces. This lab briefly surveys basic debugger capabilities by applying GDB to a small program drawn from the current programming project. Determining the behavior and required inputs for the program is made immensely easier through the use of the debugger.

Associated Reading

CSCI 2021 Quick Guide to gdb: The GNU Debugger: Page describing how to start the debugger, a sample session using puzzlebox, an overview of the most common commands.

Grading Policy

Credit for this Lab is earned by completing the exercises here and submitting a Zip of the work to Gradescope. Students are responsible to check that the results produced locally via make test are reflected on Gradescope after submitting their completed Zip. Successful completion earns 1 Engagement Point.

Lab Exercises are open resource/open collaboration and students are encouraged to cooperate on labs. Students may submit work as groups of up to 5 to Gradescope: one person submits then adds the names of their group members to the submission.

See the full policies in the course syllabus.

2 Codepack

The codepack for this lab is linked at the top of this document. Always download it and unzip/unpack it. It should contain the following files which are briefly described.

File Use Description
QUESTIONS.txt EDIT Questions to answer: fill in the multiple choice selections in this file.
phase03.c Analyze C program that emulating part of P2's puzzlebox
input.txt EDIT Input file for phase03 which should be edited to contain correct inputs.
Makefile Build Enables make test and make zip
QUESTIONS.txt.bk Backup Backup copy of the original file to help revert if needed
QUESTIONS.md5 Testing Checksum for answers in questions file
test_quiz_filter Testing Filter to extract answers from Questions file, used in testing
test_lab06.org Testing Tests for this lab
testy Testing Test running scripts

3 QUESTIONS.txt File Contents

Below are the contents of the QUESTIONS.txt file for the lab. Follow the instructions in it to complete the QUIZ and CODE questions for the lab.

                           __________________

                            LAB 06 QUESTIONS
                           __________________





Lab Instructions
================

  Follow the instructions below to experiment with topics related to
  this lab.
  - For sections marked QUIZ, fill in an (X) for the appropriate
    response in this file. Use the command `make test-quiz' to see if
    all of your answers are correct.
  - For sections marked CODE, complete the code indicated. Use the
    command `make test-code' to check if your code is complete.
  - DO NOT CHANGE any parts of this file except the QUIZ sections as it
    may interfere with the tests otherwise.
  - If your `QUESTIONS.txt' file seems corrupted, restore it by copying
    over the `QUESTIONS.txt.bk' backup file.
  - When you complete the exercises, check your answers with `make test'
    and if all is well, create a zip file with `make zip' and upload it
    to Gradescope. Ensure that the Autograder there reflects your local
    results.
  - IF YOU WORK IN A GROUP only one member needs to submit and then add
    the names of their group.


QUIZ gdb basics and phase03.c
=============================

Starting Up
~~~~~~~~~~~

  After starting up GDB with the `phase03' program, the `run' command
  will yield the following output
  ,----
  | > gdb ./phase03
  | ...
  | 
  | (gdb) run
  | Starting program: ./phase03 
  | usage: ./phase03 <infile>
  | [Inferior 1 (process 1943881) exited with code 01]
  `----
  which means that the `phase03' program wants a command line
  argument. How does one accomplish this in GDB?
  - ( ) Use the command `set args input.txt' once and then each `run'
    will use those arguments
  - ( ) Use the command `run input.txt' each time you run
  - ( ) Either of the above will work
  - ( ) Start GDB as `gdb ./phase03 input.txt'


Setting a Breakpoint
~~~~~~~~~~~~~~~~~~~~

  Which of the following commands will set a breakpoint in GDB at the
  line that reads `int hit = shot ^ targ;'?
  - ( ) `break int hit = shot ^ targ'
  - ( ) `break phase03'
  - ( ) `break phase03.c:32'
  - ( ) `break next hit'

  After hitting the specified breakpoint, which of the following GDB
  commands will advance to the next **breakpoint** that is set?
  - ( ) `next'
  - ( ) `continue'
  - ( ) `run'
  - ( ) `advance'


next command in gdb
~~~~~~~~~~~~~~~~~~~

  During a debugging, the debugger has `phase03' stopped at the line
  indicated below via a `>' character.
  ,----
  | /// INITIAL ///
  |   void phase02(){
  |     int a = atoi(next_input());
  | >   int b = atoi(next_input());
  |     int c = atoi(next_input());
  | ....
  | 
  |   char *next_input(){
  |     input_idx++;
  |     int ret = fscanf(input_fh, "%s", inputs[input_idx]);
  | ...
  | 
  `----

  When the `next' command is executed by GDB, then the debugger executes
  some code and leaves the state of the running program in one of the
  following positions:

  ,----
  | /// OPTION A ///
  |   void phase02(){
  |     int a = atoi(next_input());
  |     int b = atoi(next_input());
  | >   int c = atoi(next_input());
  | ....
  | 
  |   char *next_input(){
  |     input_idx++;
  |     int ret = fscanf(input_fh, "%s", inputs[input_idx]);
  | ...
  | 
  | /// OPTION B ///
  |   void phase02(){
  |     int a = atoi(next_input());
  | >   int b = atoi(next_input());
  |     int c = atoi(next_input());
  | ....
  | 
  |   char *next_input(){
  |     input_idx++;
  |     int ret = fscanf(input_fh, "%s", inputs[input_idx]);
  | ...
  | 
  | /// OPTION C ///
  |   void phase02(){
  |     int a = atoi(next_input());
  |     int b = atoi(next_input());
  |     int c = atoi(next_input());
  | ....
  | 
  |   char *next_input(){
  | >   input_idx++;
  |     int ret = fscanf(input_fh, "%s", inputs[input_idx]);
  | ...
  `----

  After executing `next', which option correctly indicates where GDB
  will get control back?
  - ( ) OPTION A because `next' moves to the next line of code executing
    all functions and operations on a given line.
  - ( ) OPTION B because `next' executes the next operation and
    completes it which will be the `next_input()' function but the
    `atoi()' function will not be run
  - ( ) OPTION C because `next' steps into functions and executes the
    next operation which is to start running the `next_input()'
    function.


step command in gdb
~~~~~~~~~~~~~~~~~~~

  Instead of using the `next' command in the above example, what if the
  `step' command was used instead from the `INITIAL' position? Which
  `OPTION' represents the code position GDB would be at after `step'?

  - ( ) OPTION A because `step' moves to the next line of code executing
    all functions and operations on a given line.
  - ( ) OPTION B because `step' executes the next operation and
    completes it which will be the `next_input()' function but the
    `atoi()' function will not be run
  - ( ) OPTION C because `step' steps into functions and executes the
    next operation which is to start running the `next_input()'
    function.


CODE input.txt for phase03
==========================

  The mock `phase03' program can be compiled via `make' and run via
  ,----
  | > ./phase03 input.txt
  `----


  Use `gdb' and analyze what inputs are required in the file `input.txt'
  in order to "pass" the phase. A correct run yields the output:
  ,----
  | > ./phase03 input.txt
  | Running mock Phase03
  | Right on target: nice shootin' bitslinger!
  | Phase complete
  `----
  which is checked for in the CODE tests.

  Test that the code behaves correctly via the command
  ,----
  | make test-code
  `----

  and verify that both code/quiz are correct via
  ,----
  | make test
  `----

  before using
  ,----
  | make zip
  `----

  to create a zip to submit.


Hints to Determine the Input
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  - There are 4 input numbers required for the phase and these are
    extracted from the input.txt file
  - There is a variable called `targ' which is important to examine; you
    may wish to examine its value carefully using gdb's `print' command;
    set a breakpoint after `targ' has its value set and try the
    following commands
    ,----
    |   gdb> print targ     # print as decimal int
    |   gdb> print/x targ   # print as hexadecimal
    |   gdb> print/t targ   # print in binary
    `----

4 Submission

Follow the instructions at the end of Lab01 if you need a refresher on how to upload your completed lab zip to Gradescope.


Author: Chris Kauffman (kauffman@umn.edu)
Date: 2023-02-23 Thu 08:41