讲解 Project 2调试R程序

Project 2

How to Succeed on this Project

1. Read the entirety of this specification in detail. It contains a lot of information that will make the project go more smoothly in you take the time to understand it before starting the project.

2. Know the purpose of each file in the starter code. You will only need to modify two files to complete the project, but you should read this specification to understand why the other files are present. In particular, understand which files you are or are not allowed to modify to avoid autograder issues.

3. Know how to run your code independently of the Makefiles we provide. Particularly on this project, the test results are not enough to tell you what is going wrong with your code. You will need to be able to test out your code manually to figure out precisely where it may be producing undesirable results.

4. Expect to get stuck, and exercise patience and persistence. This project does not involve writing a large quantity of code. Rather, it involves solving a series of "puzzle" problems that will take time and thinking to solve. Do not expect the solutions to these puzzles to be immediately clear to you. Instead, you will initially be stuck and will have to think through them, perhaps using a pen and paper to work through different examples. Getting stuck like this is a normal part of the learning process in STEM subjects. We are happy to help in office hours but will not give out answers -- we can only point you in the right direction or suggest helpful examples to consider.

5. Start early. Give yourself time to get stuck, discover insights about the puzzles, and overcome obstacles. It can be hard to think creatively about solutions to programming problems like those in this project when you feel the pressure of an imminent deadline.

6. If you have questions, your best option is to ask in a public Piazza post. This gets your question in front of as many people as quickly as possible, and also lets others benefit later by seeing the answer to your question.

7. Familiarize yourself with the late submission policy detailed in the [syllabus](syllabus) so that you are not caught off-guard. No submissions are accepted more than 48 hours after the deadline. Extensions are generally not granted for projects except in the case of a documented and acute emergency.

8. The two parts of this project are independent, so you should feel free to switch between them. If you get stuck in Part 1, try making some progress on Part 2, and vice versa.

Introduction

This project consists of two parts. In the first part, you will solve a series of programming problems involving bitwise operations and data representations. In the second part, you will use a debugger to run and inspect the workings of a puzzle program to reverse engineer it and deduce the input values needed to run the program successfully to completion. Bit-level operations are common in C and in systems programming. In Part 1 of this assignment, you will write code involving these operations to become more familiar with the bit-level representations of integers. You will do this by solving a series of programming "puzzles." Many of these puzzles are artificial, but you will find yourself thinking much more deeply about bits in order to solve them. Debugging code is also a critical aspect of real programming that is greatly aided through use of a debugger tool. In Part 2 of this project, you will use the GNU Debugger, gdb, to work through a puzzle program requiring specific inputs to pass its sequence of "phases."

Grading Criteria

Credit for this assignment will be awarded based on three categories:

Automated Testing of Bitwise Puzzles (23%): The starter code includes two programs that will test your bitwise puzzle solutions. The first program checks that your code adheres to the requirements stated below, while the second program runs your puzzle solutions against a variety of inputs. We will use these same programs when autograding your work.

Automated Testing of Puzzlebox Solution (77%): We will run the provided puzzlebox program against inputs stored in a file you submit and will check to see how many phases of the program are successfully completed with your input values.

Starter Code

Download the zip file linked at the top of this page to obtain the starter code for this project. You should see the following files. You may only modify the files marked "Edit" under the "Purpose" column below. The autograder will use the starter versions of all other files when grading your work.

Part 1: Bitwise Puzzles

Read the material below and the comments at the top of bits.c to understand how to complete this part of the project.

The first part of the project focuses on the files in the bitwise directory. We recommend that you work within this subdirectory of the starter code for the duration of this part of the project (e.g., by using cd in your terminal).

The first thing you will likely want to do is run the make command within this subdirectory to compile the starter code and the useful utilities it provides (described below).

Note: If you wish to compile this code in your own Linux environment rather than the CSE Labs machines, you will need to install 32-bit variants of the standard C libraries. With Ubuntu, you can do this with the following command:

sudo apt install gcc-multilib

Your task is to fill in the skeleton code in the bits.c file with solutions to 9 bitwise puzzle problems.

You can only use straightline C code for the integer-related puzzles (i.e., no loops or conditionals) and a limited number of C arithmetic and logical operations.

Specifically, you are only allowed to use the following eight operators:

! ~ * ^ | + << >>

A few of the problems further restrict this list.

Also, you are not allowed to use any constants larger than 8 bits (e.g., you can use 0xFF but not 0xFFF).

You are also not allowed to use binary constants like 0b1001 in your solutions.

You may not use any structs, unions, or arrays.

Most significantly, you may not use any floating-point data types, operations, or constants.

The Puzzles

The puzzles that you will be solving in bits.c are described below, in the same order as their appearance in the provided code.

The puzzles are ordered roughly from least difficult to most difficult. The "Rating" column gives the difficulty rating (which also corresponds to the number of points awarded for solving the puzzle). The "Max Ops" column gives the maximum number of operations you are allowed to use in your solution.

You may also want to look at the contents of tests.c to see reference functions that express correct behavior. of your functions, although they do not satisfy the coding requirements expected of your solutions.

Checking Your Work

To check if your puzzle solutions comply with the required coding standards (number of ops, no conditionals, etc.), use the provided dlc program. Note that this program is provided to you as a pre-compiled binary and will only work within Linux environments.

If you solutions are all compliant, dlc will not produce any output, like so:

> ./dlc bits.c

If one or more of your solutions violate a coding rule, dlc will provide an error message like so:

./dlc bits.c

dlc:bits.c:145:bitNor:Illegal constant (0xFFF) (only 0x0 - 0xff allowed)

Note that dlc identifies both the puzzle solution that violates the rule as well as the rule violated.

You will not receive autograder credit for your bitwise puzzle solutions if the dlc checks do not pass. If you are unable to solve a puzzle within the constraints, your best option is to remove the non-compliant solution before submission so that you still receive credit for the rest of your solutions.

Next, you can use the very helpful btest program to check your solutions. To check all solutions, run btest like so:

The above output is from running btest on the starter code, which initially fails all tests.

Code with solutions to all puzzles will produce the following output:

Learn how to use the features of the btest program to test your solutions individually and with specific input values.

This will be much more helpful than running btest in its default configuration.

The btest program will provide you with helpful documentation when run with the -h argument:

You can use btest to test a specific puzzle solution and with specific input values. For example, to test your solution to the bitOr puzzle with input values 0xAB and 0xCD, you would run:

Notice that btest can take arguments expressed in either decimal or in hexadecimal.

Other Advice

Don't include the header file in your bits.c file, as it will confuse the dlc checker and results in some non-intuitive error messages. You will still be able to use printf in your code if you want to, although gcc will print a warning that you can ignore.

Also, the dlc program enforces a stricter form. of C declarations than what is enforced by gcc. In particular, any declaration must appear in a block (i.e., a chunk of code enclosed by curly braces) before any statement that is not adeclaration. For example, dlc will complain about the following code:

Specifically, dlc will emit an error message stating that b is an undeclared variable.

Use the provided ishow tool, which is generated when you compile code with make. This can help you see how integer and values are represented.

You can use the bitwise/Makefile to automate the compilation and testing processes. The command make will compile your code, while make btest will compile the test harness.

Part 2: Debugging the Puzzlebox

The file puzzlebox/puzzlebox.c contains source code that reads input from a file named on the command line (usually input.txt in this project). If the inputs are correct, points are awarded. If inputs are incorrect, error messages are printed.

The puzzlebox is arranged into a series of phases, each of which has some points associated with it.

Each phase reads input from the file provided on the command line and performs calculations on them to see if they are are "correct" according to various criteria specified in the source code.

The very first input is your UMN Internet ID like exle0002 (the first part of your UMN email address). This input is used to add an element of randomness to the puzzle so that your answers will be different from most other students. You must use your own Internet ID, and we will be verifying this when manually grading project submissions. If you do not adhere to this rule, you will not receive credit for this part of the project.

The purpose of this exercise is to get familiar using a debugger. This is a powerful tool that pauses program execution, allows internal values to be printed out and inspected, and code to be stepped through line by line. It is nearly essential to use here as the code in puzzlebox is intentionally convoluted in places. Being able to pause execution and print values at various points makes it much easier to solve the puzzles.

input.txt Input File

Name your input file input.txt and put your Internet ID in the first line along with some initial numbers for the first phase like 1 2 3. Then, compile and run the puzzlebox program on it.

Initially, you will not see positive results (0/60 points), but the real meat of the project is in examining the source code, running gdb on the puzzlebox program, and determining the correct inputs for input.txt.