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:
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.
qemuon the command line, ensure that the following is added to your
We highly recommend you use a patched version of QEMU instead of the stock version that may come with your distribution. The version installed on the deparment cluster is already patched. To build your own patched version of QEMU:
|debug-seg||Use DS-relative virtual addresses instead of linear addresses in the GDB stub.|
|info-pg||Add "info pg" in the QEMU monitor that prints the page table.|
|triple||On triple fault, dump state and halt for inspection instead of resetting.|
You can access Bochs on the department cluster by ensuring that your
environment variable contains the following path:
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
gdb-stub for debugging with
these executables have been pre-built on the department cluster.
To build your own patched version
--with-x --with-x11 --with-term --with-noguito
bochsbinary with SMP support that can be used with both
pintos. This bochs binary supports an internal debugger shipped with bochs.
/path/to/bochs-gdb-installfor the install directory to avoid overwriting the previous installation.
/path/to/bochs-gdb-install/bindirectory. Go to this directory and rename the
mv bochs bochs-gdb.
bochsfrom 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
cdinto the Bochs directory, then type:
--dry-runoption if you want to test whether the patches would apply cleanly before trying to apply them.
QEMU=/path/to/qemu-1.0-CSL373-install/bin/qemu-system-i386(or ensure that
qemuis in your path).
bochsis in your executable search path.
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.
cscope/ctagswith vi: Vim/cscope tutorial, Vim/ctags tutorial
apt-get install subversion".
$ ssh ssh1.iitd.ernet.in # use your proxy password $ mkdir svn $ cd svn $ svnadmin create pintos-repoYou should see a subdirectory called
pintos-repo/README.txt. Do not add, delete, or modify any files in this subdirectory. Edit the
svn/authzfile to provide read-write permissions to
pintos-repoto yourself and your partners, and read permissions to
sbansal. For example, if users
cs1067890are partners and user
cs1012345is 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
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:
$HOME. (The permission of individual files in
$HOMEshould be restricted only to the users, so that others can't peep into user's home)
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/serversto 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-repoto 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:
?" in the
statuscommand and which you would like to add to the repository.
svn updatebefore 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]