105,7 → 105,7 |
browse Subversion repository from the web. We altered it a little bit to also |
show number of commits per developer on our homepage. |
|
\item [WHUPS] is another component of the Horde framework. It provides |
\item [Whups] is another component of the Horde framework. It provides |
feature request and bug tracking features. However, in the light of being rather |
closed group of people, we used this tool only seldomly. On the other hand, |
any possible beta tester of our operating system has had a chance to |
163,7 → 163,7 |
in our project. These invaluable programs really sped the code-compile-test cycle. |
In some cases, they were, and still are, the only option to actually run HelenOS on certain |
processor architectures, because real hardware was not available to us. Using virtual environment |
for developing our system provided us with deterministic environment on wich it is much easier to do |
for developing our system provided us with deterministic environment on which it is much easier to do |
troubleshooting. Moreover, part of the simulators featured integrated debugging facilities. |
Without them, a lot of bugs would remain unresolved or even go unnoticed. |
|
194,7 → 194,7 |
to Bochs brewing in its developer community. |
|
The biggest virtue of Bochs is that it has traditionally supported SMP. For some time, Bochs |
has been our only environment on wich we could develop and test SMP code. Unfortunatelly, |
has been our only environment on which we could develop and test SMP code. Unfortunatelly, |
the quality of SMP support in Bochs was different from version to version. Because of SMP |
breakage in Bochs, we had to avoid some versions thereof. So far, Bochs versions 2.2.1 and 2.2.6 |
have been best in this regard. |
230,7 → 230,7 |
eventually fixed. |
|
\subsection{PearPC} |
PearPC is the only emulator on wich we have run ppc32 port of HelenOS. It has |
PearPC is the only emulator on which we have run ppc32 port of HelenOS. It has |
no debugging features, but fortunatelly its sources are available under |
an open source license. This enabled {\OP} and {\MD} to alter its sources |
in a way that this modified version allowed some basic debugging. |
246,7 → 246,7 |
machine. |
|
\subsection{Simics} |
Simics simulator can be compared to a Swiss-army knife for operating system debugging. |
Virtutech's Simics simulator can be compared to a Swiss-army knife for operating system debugging. |
This proprietary piece of software was available to us under an academic license for free. |
|
Simics can be set to simulate many different configurations of many different machines. |
264,6 → 264,37 |
page was found (\#4214). As for mips32, Simics misemulated {\tt MSUB} and {\tt MSUBU} instructions. |
|
\subsection{Ski} |
The ia64 port of HelenOS has been developed and debugged on the HP's IA-64 Ski simulator. |
Ski is just an Itanium processor simulator and as such does not simulate a real machine. In fact, there |
is no firmware and no configuration tables (e.g. memory map) present in Ski! On the other hand, the missing parts can be supplied externally\footnote{This |
is actually how Linux runs in this simulator.}. The simulator provides means of interaction with |
host system devices via Simulator SystemCalls (SSC). The simulator itself has graphical interface |
with pretty powerful, but not as good as those of Simics, debugging facilities. |
|
Ski is a proprietary program with no source code available. Its binaries are available |
for free under a non-free license. It comes packaged with insufficient documentation |
which makes the development pretty problematic. For instance, there is no public documentation |
of all the SSC's. All one can do is to look into Linux/ia64-Ski port, which was written by the |
same people as Ski, and use it as a refernce. We had to look into Linux once more when our kernel |
started to fail in some memory-intensive stress tests. In fact, the problem was that the tests |
hit the IA-32 legacy videoram area. We fixed the problem, in the light of absence of any memory map, by blacklisting |
this piece of memory to our frame allocator. |
|
The way HelenOS is booted on Ski is by simply loading its ELF image |
and jumping to it. The ELF header contains two fields describing where and how to load the program image into memory: |
VMA and LMA. VMA\footnote{Virtual Memory Address} is an address where the program's segment gets mapped in virtual memory. |
LMA\footnote{Load Memory Address} is the physical address where the segment is loaded in memory. {\JV} discovered |
that Ski confuses VMA and LMA. This, what we believe to be a bug in Ski, has not shown in Linux since Linux always has |
LMA equal to VMA. People from the Ski mailing list had tried to help us but our repeated problem report didn't |
make it far enough for the HP to fix or at least clarify the issue. Finally, we adopted a workaround implemented by {\JJ} |
that simply swaps LMA and the program entry point in the kernel ELF image. |
|
\subsection{VMware} |
VMware is the only virtualizer we have used in HelenOS development. It virtualizes the ia32 host machine. |
Since VMware version 5.5, we made use of its possibility to run the guest system (i.e. HelenOS) on multiple processors. |
VMware has no support for debugging but is very useful for compatibility and regression testing because |
it's closest to the real hardware. VMware, being a virtualizer, is also the fastest of all the virtual environments |
we have utilized. |
|
|
\section{Authoring tools} |