Please note that these assignments will not be graded.
But you are strongly encouraged to do them.
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!
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).
[ 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.
[ 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).
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.
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
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:
- 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").
- 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.
- 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.
|
