GDB Assignments – CSCI 402, Summer 2024

merlot.usc.edu/cs402-m24/projects/gdb

Please note that these assignments will not be graded. But you are strongly encouraged to do them.

Overview

In previous semesters, I noticed that some students are debugging programs the old fashion way (i.e., using print statements and observing program printouts). It’s very

painful and inefficient. (And you should never let your employer knows that this is how you debug.) You have to learn how to use a debugger when developing for a large

software project such as the weenix kernel! System Prerequisites

You are required get your code to work under Ubuntu 16.04 running QEMU 2.5 (any subversion of Ubuntu 16.04 is fine). If you don’t have such a system, please see the instructions on how to install Ubuntu 16.04 on a Windows or a Mac OS X machine.

I would prefer to see that you use gdb for all these assignments. I will also accept Eclipse. If you want to use something else, you would need the approval of the instructor (and please send the instructor an e-mail as early as possible).

General Grading Considerations

[ This section no longer applies since GDB assignments are not graded. ]

Grading is to be done by course producers during their posted helpdesk hours. You can go to any course producer to get your GDB assignments graded.

Since these are not programming assignments, you are free to discuss how to

accomplish the tasks even in the class Google Group at any level of detail! It’s perfectly okay to share information or discuss about things like the exact gdb commands to enter.

These assignments assume that the programming assignments you are working on have certain level of functionality. Please understand that if your code are not done correctly, you will not be able to follow the steps mentioned in the grading guidelines below; and thus, you will not receive credit for those parts.

Late Submission Policy

[ This section no longer applies since GDB assignments are not graded. ]

The regular late policy does not apply for these assignments since the only time these assignments can be graded is during course producers’ posted helpdesk hours.

Please note that the course producers only hold helpdesk hours during the 15 weeks of classes (and not during final exam weeks or study days).

After the 15 weeks of classes is over, if you would still like a GDB assignment graded, you can make an appointment with the instructor and get a 50% deduction in the

corresponding GDB assignment grade. My availability is unpredictable after classes are over and you need to plan ahead. The absolute deadline for getting the GDB assignments graded is (do not turn in).

GDB Assignment 1

You are required to debug listtest in Warmup Assignment #1 on Ubuntu 16.04. If you don’t know what to do, please feel free to start a discussion in the class Google Group. Grading Guidelines

(1 pt) You’ve got Ubuntu 16.04 running on your desktop/laptop.

(2 pt) Set a breakpoint at the beginning of main(). Run the equivalent of

“listtest 1 2 3” in the debugger. Print out argc, argv[0], argv[1], argv[2], and argv[3] when you are at the breakpoint and explain to the course producer what you see. Quit the debugger.

(3 pt) Set a conditional breakpoint in the middle of CreateTestList() to break when i is 10. Also set a breakpoint at the beginning of RandomShuffle(). Run the

equivalent of “listtest” in the debugger. At the breakpoint, make sure i is indeed

10. Then change both pList->anchor->next and pList->anchor->prev to NULL and continue. Your program will either crash or reach the beginning of

RandomShuffle(). In either case, do a stack trace and explain to the course producer what you see.

(4 pt) Change the first line of DoTest() to:

int num_items=3;

and recompile. Then do the following:

gdb listtest (gdb) break DoTest (gdb) run

When you get to the breakpoint, type the following command 6 times:

(gdb) n

Now you should be at the line that’s about to call CreateTestList(). Do:

(gdb) p &list.anchor (gdb) p list

Read the above printout very carefully and convince yourself that you are looking at an empty list. Then do:

(gdb) n

Now you should have just returned from CreateTestList(). You need to verify that the list is still a good list. Do:

(gdb) p list

(gdb) p list.anchor

(gdb) p *(list.anchor.next) (gdb) p *(list.anchor.next->next)

(gdb) p *(list.anchor.next->next->next)

Read the above printout very carefully. Get a piece of paper and draw a picture

that looks like the picture in the warmup1 spec, and label every part of the list and list elements and convince yourself that you are looking at a doubly-linked circular list of 3 objects (where the objects are integers with values 0, 1, and 2).

As you proceed, any time you call a function, repeat the above print statements to understand how the list is changing and make sure that you still have a valid

doubly-linked circular list.

If your my402list.c has bugs and cannot go far enough to demonstrate the above to the course producer, you will not receive points for the corresponding items.

GDB Assignment 2

You will be debugging the weenix kernel in this assignment on Ubuntu 16.04. You

need to write some working code first before you can finish with this assignment. If you don’t know what to do, please feel free to start a discussion in the class Google Group.

Grading Guidelines

(2 pt) Start debugging the weenix kernel. Show that you would get a breakpoint at the beginning of bootstrap(). List the source code and single step in

bootstrap(). When your code is about to create the idle process, step into the function and do a stack trace and explain to the course producer what you see.

(1 pt) Set a breakpoint at the beginning of idleproc_run() and show that you get there. Try the following gdb command and make sure it works:

kernel info pt_mapping_info curproc->p_pagedir

You don’t need to understand the printout. You just need to make sure that you don’t get a bunch of Python error messages. If you get a bunch of Python error

messages, it may be that you didn’t initialize and setup the page table for the idle process correctly or your curproc is pointing at the wrong place.

(1 pt) Set a breakpoint at the beginning of initproc_run() and show that you get there. Explain the output of the “kernel proc” gdb command to the course producer. List the source code and single step in initproc_run().

(2 pt) Set a breakpoint at the beginning of sched_switch() and show that you get there. Do a stack trace and explain to the course producer which process is

giving up the CPU by calling sched_switch() and why it is going to sleep and

which queue it sleeps in (you should use the stack trace to tell you where to list your code).

(3 pt) Your proc_create() should return a pointer to proc_t when a new process is created. Set a conditional breakpoint where you are about to return from

proc_create with a valid pointer to proc_t and only break if the newly created process has a PID of 2 (i.e., it’s the pageoutd). At the breakpoint, print the proc_t data structure and make sure that it has a PID of 2 and it is indeed the pageoutd process. Do a stack trace and explain to the course producer where the pageoutd process is created.

(1 pt) Set a breakpoint at the beginning of wait_for_all() in “faber_test.c” and show that you get there. Explain the output of the “kernel proc” gdb command to the course producer.

GDB Assignment 3

You will be debugging the weenix kernel and the hello user space program in this assignment on Ubuntu 16.04. You need to write quite a bit of working code first before you can finish with this assignment. If you don’t know what to do, please feel free to

start a discussion in the class Google Group. Please do string searches in the Kernel 3 FAQ to figure out how to proceed with this assignment.

Grading Guidelines

(2 pt) Set a breakpoint at the startup routine (i.e.,     libc_static_entry()) of the hello user space program and show that you can get there. Set a breakpoint at handle_pagefault() and show that if you do a single-step in gdb at

   libc_static_entry() of hello, you will reach handle_pagefault().

(2 pt) In handle_pagefault(), display the virtual memory map by issuing the

“kernel info vmmap_mapping_info curproc->p_vmmap” gdb command and explain to the course producer what you see. You will not get full credit if your virtual memory map looks “wrong”.

(2 pt) Use the “add-symbol-file user/usr/bin/hello.exec 0x08048094” gdb

command to add debugging information about the “/usr/bin/hello” user space program into gdb. Set a breakpoint in main() and continue. When you get to

main() in user space, type “list” to see the code in “hello.c“. In order to get to

main() in user space, your need to handle the first two page faults correctly.

(2 pt) The hello user space program simply makes 4 system calls. It calls

open() twice, write() once, and exit() once. Set a breakpoint at

syscall_dispatch() and show how the kernel reaches sys_open(), sys_write(), and do_exit(). In order to get to all these breakpoints, your need to handle the all the page faults correctly.

(2 pt) The hello user space program simply makes 4 system calls. It calls

open() twice, write() once, and exit() once. Show the course producer how you would do the following:

1. Step into the write() C library function. Single step a few statements to get to the trap() function (defined in “user/include/weenix/trap.h“).

2. When you get inside the trap() function, list the C code for trap(). You

   should see that it invokes the software interrupt machine intructions twice. Switch gdb layout to “asm” mode. Location the two trap machine instructions (“int 0x2e“). Step breakpoints on the machine instructions immediately

   after these two trap machine instructions.

3. Use the gdb “cont” command to execute till it returns from the first trap

machine instruction. Use the gdb “info registers” command to display the values of the CPU registers. Explain the values of eax, esp, ebp, and eip to the course producer.