Hey everyone,
I'm trying to build gdb for sys161 on x86 linux but I get some errors in
the bfd library. Did anyone have these errors, and if so how'd you fix
them? If you have a successfully built version, could you send the
binary to me? (I assume they're statically linked, right?)
Thanks,
Dave
It was brought to my attention recently that gdb connected to sys161
would refuse to print strings unless they were aligned to start on a
word boundary.
This is badly broken and shouldn't have been tolerated -- I wish
someone had told me earlier. It ought to be working now. A new sys161
release (0.99) has been issued and is posted in the usual places.
(The funny part is, I'm sure I remember fixing this problem already
once. I guess it regressed.)
--
- David A. Holland / dholland(a)eecs.harvard.edu
Greetings --
Hopefully everyone is finishing up assignment 4. A quick note on that --
there was some confusion on what type of crash consistency you need to
enforce (e.g., FFS forces meta-data to write synchronously). You don't
have to implement any -- i.e., you don't need to worry about the case
where your system crashes. Our apologies on an confusion on this point.
On to assignment 5 -- please send mail to your TFs by Sunday morning (9:00
am) letting them know what topics you are considering. Your TF will then
aim to cover that in section.
thanks,
-mike
A. Student wrote:
> I was wondering why badcall expects EFAULT to be returned when the
> empty string is passed to rmdir (and other similar calls).
> Technically, the memory address is valid, so wouldn't ENOENT make
> more sense?
Because it's broken, and the test framework in badcall isn't powerful
enough to allow fixing it with a simple patch but rather needs a
complete rewrite.
So everyone please ignore its complaints about error returns on
empty-string tests.
:-|
--
- David A. Holland / dholland(a)eecs.harvard.edu
Due to scheduling conflicts, we're rearranging office hours for
tomorrow. Office hours will be held at the following times:
Georgi: 7-9 pm
Nick: 9-11 pm
If you were somehow counting on a TF being available from 11-midnight,
let us know and we can work something out.
Nick
Some sharp-eyed people noticed something missing from an error-return
path in vfs_open. Patch follows, will be posted on the web site, etc.:
Index: src/kern/fs/vfs/vfspath.c
===================================================================
RCS file: /disk/disk0/cs161/CVSREPO/os161/src/kern/fs/vfs/vfspath.c,v
retrieving revision 1.5
diff -u -r1.5 vfspath.c
--- vfspath.c 2001/09/18 22:19:20 1.5
+++ vfspath.c 2002/04/16 23:40:49
@@ -74,6 +74,14 @@
result = VOP_TRUNCATE(vn, 0);
}
if (result) {
+ int result2 = VOP_DECOPEN(vn);
+ if (result2) {
+ /* Blah. What else can we do? */
+ panic("vfs_open: Error %d from VOP_DECOPEN "
+ "trying to recover from\n"
+ "error %d handling O_TRUNC\n",
+ result2, result);
+ }
VOP_DECREF(vn);
return result;
}
--
- David A. Holland / dholland(a)eecs.harvard.edu