| 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} |