Computer System II Lab #1 Solution

$30.00

Description

1 Introduction

In this lab, you will do the following:

1. Measure the performance of each of for, while and do-while loop.

2. Measure the size of each of the functions (number of bytes).

3. Examine the shared libraries the loop program depends on.

4. Debug a program.

2 Getting Started

In this repository you will find loop.c and buggy.c. You will modify both loop.c and buggy.c.

3 Performance of loops

This task refers to contents of loop.c. Modify loop.c to invoke each of the loop functions separately from main. Create a text file called ”Lab1.txt” and report the following:

1. Number of iterations of each of for, while and do-while loops per second.

2. Average time of 3 trials where n = 1000000000 for each of the 3 loops.

3. Number of instructions in each of the 3 functions.

4. 2-3 sentences explaining why you think one type of loop runs faster than the other.

Add the necessary commands to the loop target in the Makefile in order to build the executable. Refer to Lab 0 if necessary.

Number of instructions in the loop

  1. Disassemble the program using:

1 $ objdump d l o o p > l o o p . d i s a s

2. Open loop.disas using a text editor, search each of the functions and count the number of bytes within the program. You could either take a difference between end address and start address, or you could count the number of instructions manually. Add these counts to Lab1.txt Read the man page for objdump to see other options.

4 Examining the dependencies of loop program

The “ldd” program is used to list all the dlls that a program depends on. Copy the output of the below command to Lab1.txt.

1 $ l d d . / l o o p

Add Lab1.txt to the repository and commit with any changes you made to loop.c and

Makefile to support your experiments, then push it.

5 Debugging the buggy program

The file buggy.c contains 5 distinct bugs. You are to identify and fix the bugs without modifying the intended behavior of the program. The comments should help clarify the intent of the code. Add the following command to your Makefile under the buggy target, replacing the error message that is currently present:

1 g c c s t d=c 8 9 f n o s t a c k p r o t e c t o r w g o b u gg y b ug g y . c

Expected output when all 5 bugs are fixed is as follows:

1 $ . / b u gg y

V a l u e o f s t r i s c

3 E n t e r s t r i n g : The q u i c k brown f o x jumped o v e r t h e l a z y d o g !

You e n t e r e d : The q u i c k brown f o x jumped o v e r t h e l a z y d o g !

5 New v a l u e o f x i s 6

x i s NOT b e t w e e n 5 and 1 0

7 x and s t r a r e e q u a l

A l l Done ! !

Running the program in gdb We will be using “gdb”, the GNU debugger to debug the crashes. Load the program using gdb as follows:

$ gdb . / bu g g y

Below, you are provided with some common gdb commands. A detailed list of commands is available here: http://web.cecs.pdx.edu/ jrb/cs201/lectures/handouts/gdbcomm.txt

Breakpoints are used to pause execution when it reaches a point of interest. Breakpoints can be applied through a function name, line number in a file, or instruction address.

1 ( gdb ) b main

This will stop execution when main function begins. Step through statements using gdb command “next”.

1 ( gdb ) n e x t

As you step through the code, you can examine the runtime values of different variables using gdb’s print command. For example, in the buggy.c program, typing the command (gdb) p/x str at any point will print the hex value of str at that given point.

Execution occurs on a stack. As control moves from one function to another, the return addresses are saved on a stack. Corruption of the return address is a common source for segmentation faults. When you encounter a segmentation fault, you can examine the execution stack using the following gdb command:

1 ( gdb ) b a c k t r a c e

If you have compiled your code using the ‘-g’ option, you can examine the source code using the command (gdb) list. Also, you can examine the assembly instructions by switching to the assembly layout using (gdb) layout asm.

Once you’ve fixed buggy.c, commit it to your repository.

6 Submitting the result

As with Lab0, after you’ve made your final commit, copy the SHA hash and make a submission on MyCourses with the hash as the comments to the submission. If you are still in class, get the attention of the Teaching Assistant to be graded. If you cannot finish the lab by the end of the lab period, you have until end of day to complete the work in your repository and make a submission on MyCourses.