CSCI 2021 Lab06: GDB Basics
- Due: 11:59pm Tue 28-Feb-2023 on Gradescope
- Approximately 1.00% of total grade
CODE DISTRIBUTION: lab06-code.zip
VIDEO DEMO: Available courtesy of TA Dat
CHANGELOG: Empty
Table of Contents
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.