It should be possible to get this development environment running under windows with the help of Cygwin. Install cygwin, and be sure to install the flex and bison packages (they are under the development header). Another alternative is to use virtualization software like VMware and install Linux in a VM.
Most modern Linuxes and BSDs have an ELF toolchain compatible with the labs. That is, the system-standard gcc, as, ld and objdump should just work. The lab makefile should automatically detect this. However, if your machine is in this camp and the makefile fails to detect this, you can override it by adding the following line to conf/env.mk:
GCCPREFIX=
If you are using something other than standard x86 Linux or BSD, you will need the GNU C compiler toolchain, configured and built as a cross-compiler for the target 'i386-csl373-elf', as well as the GNU debugger, configured for the i386-csl373-elf toolchain. You can download the specific versions we used via these links, although any recent versions of gcc, binutils, and GDB should work:
Once you've unpacked these archives, run the following commands as root:
# cd binutils-2.20.1 # ./configure --target=i386-csl373-elf --disable-nls # make # make install # cd ../gcc-4.5.1 # ./configure --target=i386-csl373-elf --disable-nls --without-headers \ --with-newlib --disable-threads --disable-shared \ --disable-libmudflap --disable-libssp # make # make install # cd ../gdb-6.8 # ./configure --target=i386-csl373-elf --program-prefix=i386-csl373-elf- \ --disable-werror # make # make install
Then you'll have in /usr/local/bin a bunch of binaries with names like i386-csl373-elf-gcc. The lab makefile should detect this toolchain and use it in preference to your machine's default toolchain. If this doesn't work, there are instructions on how to override the toolchain inside the GNUmakefile in the labs.
debug-seg | Use DS-relative virtual addresses instead of linear addresses in the GDB stub. |
info-mem | Fix "info mem" in the QEMU monitor to not skip the last mapped memory range. |
info-pg | Add "info pg" in the QEMU monitor that prints the page table. |
e100 | Fixed bugs in QEMU's simulated E100 and adds E100 debugging. |
pcap | Adds packet capture support. |
triple | On triple fault, dump state and halt for inspection instead of resetting. |
We highly recommend you use a patched version of Bochs instead of the stock
version to allow reproducible executions. The version installed on the
department cluster is already patched. There are two executables that
need to be built: bochs
(which is compiled with
an internal debugger) and bochs-gdb
(which is compiled with
a gdb-stub
for debugging with gdb
). Both
these executables have been pre-built on the department cluster.
To build your own patched version
of Bochs:
--with-x --with-x11 --with-term --with-noguito
configure
.
bochs
binary with SMP support
that can be used with both xv6
and pintos
. This
bochs binary supports an internal debugger shipped with bochs./path/to/bochs-gdb-install
for the install directory to
avoid overwriting the previous installation.
/path/to/bochs-gdb-install/bin
directory. Go to this
directory and rename the bochs
executable to
bochs-gdb
using mv bochs bochs-gdb
./path/to/bochs-install
and
/path/to/bochs-gdb-install
directories.
bochs
from
scratch (instead of using our custom tarball), you can download the
official 2.4.5 source tarball from
the Bochs homepage and apply the following patch series:
These patches are designed for use with Bochs 2.4.5:
jitter | Adds the "jitter" feature, in which timer interrupts are delivered at random (but reproducible) intervals. |
att | Sets the default disassembly mode to AT&T (also
used in the handouts and class). |
cd
into the Bochs directory, then
type:
patch -p1 < bochs-2.4.5-jitter.patch
|
|
patch -p1 < bochs-2.4.5-att.patch
|
patch
's --dry-runoption if you want to test whether the patches would apply cleanly before trying to apply them.
QEMU=/path/to/qemu-0.12.5-6828/i386-softmmu/qemu
BOCHS=/path/to/bochs-install/bin/bochsGo to the xv6 directory. Run
make qemuto run xv6 inside Qemu.
make bochsto run xv6 inside Bochs. Remember to type ldsym "kernel.sym" at the prompt after running
make bochs
. This will load all the symbol to address mappings to
help you in debugging.
pintos/src, by executing
gunzip /path/to/pintos.tar.gz | tar x |
Go to src/threads
directory and type make
. Go inside
the newly created src/threads/build
directory.
Before we proceed,
ensure that bochs
, qemu
, and the
pintos
utility are in your path.
Put bochs
and bochs-gdb
in your path using:
export PATH=/path/to/bochs-install/bin:/path/to/bochs-gdb-install/bin:$PATHNote that
/path/to/bochs-install
and /path/to/bochs-gdb-install
should be the same as you used
in your bochs installation.export PATH=/path/to/qemu-0.12.5-6828/i386-softmmu:$PATH
/path/to/qemu-0.12.5-6828
should be the same as that used while
installing Qemu.src/utils/pintos
in the following manner:
src/utils/pintos
:
my ($bin) = $debug eq 'monitor' ? 'bochs-dbg' : 'bochs';with
my ($bin) = $debug eq 'monitor' ? 'bochs' : 'bochs-gdb';
src/devices/block.c
in the following manner:
block_print_stats()
in src/devices/block.c
:
for (i = 0; i < BLOCK_CNT; i++)with
for (i = 0; i < BLOCK_ROLE_CNT; i++)
Put the pintos utility in your path using:
cd /path/to/pintos chmod +x src/utils/pintos export PATH=/path/to/pintos/src/utils:$PATHTo ensure that your
PATH
environment variable is correctly set
in each login session, you may want to add the following line to your
.cshrc
(or .bashrc
) file:
export PATH=/path/to/pintos/src/utils:/path/to/qemu-0.12.5-6828/i386-softmmu/:/path/to/bochs-install/bin:/path/to/bochs-gdb-install/bin:$PATHTo run pintos, go to
src/threads/build
directory and
type:
pintos --bochs --to run the basic pintos OS inside bochs. Notice that the final "
--
"
is required to let the script know that all arguments preceeding it are
arguments to the script and not to the OS itself. Any arguments given after
"--
" are arguments to the OS. For example, the following
command
pintos --bochs -- -qpasses the "
-q
" argument to the OS which causes it to quit after
it's boot is finished.pintos --qemu --To run Bochs under gdb, use
pintos --gdb --
pintos-gdb kernel.o
kernel.o
is your compiled kernel from where gdb
should load the symbol table.
cscope/ctags
with vi: Vim/cscope tutorial, Vim/ctags tutorialapt-get install subversion
".
pintos-repo
":
$ ssh ssh1.iitd.ernet.in # use your proxy password $ mkdir svn $ cd svn $ svnadmin create pintos-repoYou should see a subdirectory called
pintos-repo
in the svn
directory. Read pintos-repo/README.txt
. Do not add, delete,
or modify any files in this subdirectory.
Edit the svn/authz
file to
provide read-write permissions to pintos-repo
to
yourself and your partners, and read permissions to sbansal
.
For example, if users cs1012345
and cs1067890
are partners and user cs1012345
is currently logged in, here
is a sample authz file to use:
[/] [pintos-repo:/] cs1012345@IITD.ERNET.IN = rw cs1067890@IITD.ERNET.IN = rw sbansal@IITD.ERNET.IN = rNotice that your username should be suffixed with
@IITD.ERNET.IN
and not cse.iitd.ernet.in
. These statements provide
read/write access to the group partners and read access to the instructor.
Read access to the instructor is necessary for submission of assignments.
Set the directory permissions so that they look like the following:
drwx-----x
for $HOME
. (The permission of individual files in $HOME
should be restricted only to the users, so that others can't peep into user's home)drwx------
for $HOME/svn
Go to one of the machines in the department cluster (or your local machine). Use the following command to checkout the files from your repository:
$ svn checkout https://svn.iitd.ernet.in/~cs1012345/pintos-repoYou will be prompted for your CSC password. Do not offer to save the password in plaintext format in your home directory as that is insecure. You can add the following line to
~/.subversion/servers
to avoid getting prompted for saving passwords in future:
store-plaintext-passwords = noThis should create a directory called
pintos-repo
.
Type the following commands to add the base pintos files to the
repository:
$ cd pintos-repo/ $ cp -r /path/to/pintos/src . $ svn add src $ svn commit"
svn add
" adds the files to your local checked-out copy of
the repository. "svn commit
" commits the changes in your
local repository to the main repository. You will be prompted for your
CSC proxy password each time you access the main repository. At this
point, you have successfully setup your repository. Your partner
can use
svn checkout https://svn.iitd.ernet.in/~cs1012345/pintos-repo
to checkout a copy of the code. Just like you, your partner
is also authorized to make changes and commit
them to the main repository.
If this does not work, carefully study the instructions given at the CSC Webpage on creating, accessing, and securing your repositories. Report any missing instructions that you find to the course staff so that we can fix the documentation.
Here are some more useful commands:
svn status
svn add
?
" in the status
command and which you
would like to add to the repository.
svn delete
svn update
svn commit
svn update
before this if your partner
has committed some changes after your last update. If some of your
changes conflict with your partner's changes, you may have to resolve
them manually and then use svn resolved filename
.
svn log https://svn.iitd.ernet.in/~cs1012345/pintos-repo
svn help [status|add|update|commit]