i don't understand this:
frichard@is01 sh/ $ gcc -Wall -DHOST -ggdb *.c -o host-sh
frichard@is01 sh/ $ gdb host-sh
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "alphaev56-dec-osf4.0d"...
(gdb) b main
Breakpoint 1 at 0x1200031c4: file sh.c, line 428.
(gdb) run
Starting program: /home05/f/r/frichard/courses/cs161/src2/bin/sh/host-sh
OS/161$
so, it says it'll berak at main, but it prints the prompt, which it shouldn't
until after it gets into main. it won't break on any other function i try,
either. is -ggdb the wrong flag? -g doesn't work either. any ideas?
brady
Regular sections will not be occurring this week. We'll be holding
review sessions later on (so as to be closer to the final).
The times for the review sessions are TBA, but we're looking at one on
Thursday (probably during the normal class time) and one on Sunday
afternoon or evening. If both these times are problematic for you,
please let us know ASAP.
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
Hi Folks,
For your studying convenience (and to remind you about this whole "final
exam" thing) we have put up a copy of the 1999 final exam on the website.
You can get it under the Handouts link on the main page.
A couple of notes:
1) The final asks questions about a paper. You do not have a copy of this
paper, so don't worry about those questions. If you really want a copy of
the paper, I think we can arrange to get it for you (No promises though).
2) If possible, use the PS or PDF versions of the final, as the html
version has numbering that is unintelligible.
3) The final makes references to various Nachos-isms. If you've got a lot
of free time, you can look over Nachos at this link (though you should be
able to answer nearly all of the questions in the exam without Nachos
info):
http://www.cs.washington.edu/homes/tom/nachos/
(For those of you saying "what is this Nachos madness?", Nachos was the OS
platform 161 used the last time it was offered.)
That should be about all.
Sorry for the long email.
Jay
==
== Jay Moorthi * 617.584.2537 (cell) * moorthi(a)fas.harvard.edu ==
== ==
== "Happiness consists in getting enough sleep." RAH, Starship Troopers ==
==
Folks,
We finally have a preliminary design for the shirt. It's not quite what
the original idea was, but it's still pretty cool, so hopefully you'll
still all want one. You can check it out at:
http://hlavac.www.media.mit.edu/people/hlavac/161/tshirt161.jpg
If you want one, they're $11 each, and I need the following info from you
ASAP:
Name:
Email:
Size:
We will be placing the order extremely soon, so don't slack off or you'll
miss the shirt!
-amos
Name: Margo Seltzer
Email: margo(a)eecs.harvard.edu
Size: 2 L (margo, kirk)
1 youth medium (tynan)
1 youth small (teagan)
And you had better let me pay this time!
- Margo
In order to make OS/161 (and System/161) better next year, I'm trying
to make a list of things that ought to be fixed or changed.
Now, I have my own list, but you people are the ones who have actually
been using it and working with it, and so have a much more... personal
relationship with its design flaws.
So, if all of you could, at your leisure, let us know the top ten (or
however many - if you have forty, by all means send them all) things
you think ought to be changed.
I'm looking for things like interfaces that are poorly specified, code
that's unnecessarily illegible, things that were supposed to be
helpful but weren't, things that could be useful if they were better
but aren't useful now, and stuff like that - the sort of thing that
isn't really a bug but could still stand to be improved.
This goes for both the base system and the various solution sets.
You need not report the following issues we already know about:
- the "cannot extend frag" bug in the assembler
- the fact that gdb doesn't print local variables reliably
- the fact that gdb likes to repeat lines when stepping through functions
- gdb won't print strings with unaligned addresses
- the fact that you can't debug user-level code
- all the bugs in sfs (which are hopefully all fixed now)
Any comments you have are welcome. If you don't want us to know who
you are, create a hotmail account. (Recall that hotmail reports the IP
address of the web browser you use, so do it from the fishbowl or
someplace like that.) You can also wait until after grades are
submitted, etc.
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
It appears I've done it again. If you do a read of a whole block and
it misses in the cache, it gets back garbage instead of the correct
data, because it was overenthusiastic with the "don't bother to read
in data we're not going to use" optimization.
The patch below should fix the problem.
There's another cache bug as well, but it only happens in the
following case:
- write a data block into a buffer (making the buffer dirty)
- truncate the file, releasing the block
- (the buffer should be invalidated here, but it isn't, which is the bug)
- create a new file, using the same block for the inode
- close that file, writing the inode out *not* through the cache
- then after all that, cause the dirty buffer to be written out.
This clobbers the inode.
Because the bflush thread writes buffers out relatively promptly, this
is pretty unlikely to ever actually happen, I think, so I'm not
planning to issue a fix for now.
Patch for the read problem:
Index: src/kern/fs/sfs/sfs_vnode.c
===================================================================
RCS file: /disk/disk0/cs161/CVSREPO/os161/sol4/kern/fs/sfs/sfs_vnode.c,v
retrieving revision 1.11
diff -U5 -r1.11 sfs_vnode.c
--- sfs_vnode.c 2001/04/29 23:19:02 1.11
+++ sfs_vnode.c 2001/05/04 23:13:45
@@ -426,11 +426,12 @@
*/
assert(uio->uio_rw == UIO_READ);
return uiomovezeros(SFS_BLOCKSIZE, uio);
}
- result = buffer_get(&sv->sv_v, diskblock, 0 /* cvalid */, &kbuf);
+ result = buffer_get(&sv->sv_v, diskblock,
+ (uio->uio_rw == UIO_READ) /* cvalid */, &kbuf);
if (result) {
return result;
}
/* Perform the operation into the buffer. */
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
wasn't there discussion of beer or wine or something to celebrate the
submission of exams? are we all 21? i'm all for this! bill it to the cs
department.
-gwa-
it appears that there is very low planned turnout for my section today.
just as a heads up, if no one shows by 4:15, i'm going to head home.
i'll still be holding office hours tonight from 7-9.
-amos
Hi All,
There was a small problem with some of the #if statements in sol3 that
causes it to not compile if you don't define any page replacement
algorithms in the config file.
This patch switches the default to random, and fixes the problem.
If you run into problems where the page_replace_lru symbol is unresolved
then you can either:
1) apply this patch, or
2) choose a paging algorithm in the ASSTX config file in kern/conf.
Jay
==
== Jay Moorthi * 617.584.2537 (cell) * moorthi(a)fas.harvard.edu ==
== ==
== "Happiness consists in getting enough sleep." RAH, Starship Troopers ==
==
