Subversion Repositories HelenOS-doc

Rev

Rev 36 | Rev 51 | Go to most recent revision | Show entire file | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed

Rev 36 Rev 42
Line 171... Line 171...
171
processor architectures, because real hardware was not available to us. Using virtual environment
171
processor architectures, because real hardware was not available to us. Using virtual environment
172
for developing our system provided us with deterministic environment on which it is much easier to do
172
for developing our system provided us with deterministic environment on which it is much easier to do
173
troubleshooting. Moreover, part of the simulators featured integrated debugging facilities.
173
troubleshooting. Moreover, part of the simulators featured integrated debugging facilities.
174
Without them, a lot of bugs would remain unresolved or even go unnoticed.
174
Without them, a lot of bugs would remain unresolved or even go unnoticed.
175
 
175
 
-
 
176
Using several virtual environments for testing one architecture is well justified by the
-
 
177
fact that sometimes HelenOS would run on two and crash on third or vice versa. Sometimes
-
 
178
we found that it runs on real hardware but fails in a simulator. The opposite case was,
-
 
179
however, more common. Simply put, the more configurations, no matter whether real or virtual,
-
 
180
the better.
-
 
181
 
176
From one point of view, we have tested our system on eight different virtual environments:
182
From one point of view, we have tested our system on eight different virtual environments:
177
 
183
 
178
\begin{itemize}
184
\begin{itemize}
179
\item Bochs,
185
\item Bochs,
180
\item GXemul,
186
\item GXemul,
Line 208... Line 214...
208
Our project has not only used Bochs. We also helped to identify some SMP related problems
214
Our project has not only used Bochs. We also helped to identify some SMP related problems
209
and {\OP} from our team has discovered and also fixed a bug in FXSAVE and FXRSTOR emulation
215
and {\OP} from our team has discovered and also fixed a bug in FXSAVE and FXRSTOR emulation
210
(patch \#1282033).
216
(patch \#1282033).
211
 
217
 
212
Bochs has some debugging facilities but those have been very impractical and broken
218
Bochs has some debugging facilities but those have been very impractical and broken
-
 
219
in SMP mode. Moreover, it is possible to use the GNU debugger {\tt gbd} to connect to running
-
 
220
simulation, but this has also proven not very useful as we often needed to debug
-
 
221
problems that existed only in multiprocessor configurations, which {\tt gdb}
213
in SMP mode.
222
does not understand.
214
 
223
 
215
\subsection{GXemul}
224
\subsection{GXemul}
216
GXemul is an emulator of several processor architectures. Nevertheless, we have
225
GXemul is an emulator of several processor architectures. Nevertheless, we have
217
used it only for mips32 emulation in both little-endian and big-endian modes.
226
used it only for mips32 emulation in both little-endian and big-endian modes.
218
It seems to be pretty featurefull and evolving but we don't use all its functionality.
227
It seems to be pretty featurefull and evolving but we don't use all its functionality.
Line 249... Line 258...
249
 
258
 
250
This emulator seemed to realistically emulate the {\tt hlt} instruction,
259
This emulator seemed to realistically emulate the {\tt hlt} instruction,
251
which was nice for those of us who use notebooks as their development
260
which was nice for those of us who use notebooks as their development
252
machine.
261
machine.
253
 
262
 
-
 
263
Similar to Bochs, QEMU simulation can be aided by {\tt gdb}. Debugging
-
 
264
with {\tt gdb} can be pretty comfortable\footnote{Especially when the kernel is
-
 
265
compiled with {\tt -g3}.} until one needs to debug a SMP kernel running on multiple
-
 
266
processors.
-
 
267
 
254
\subsection{Simics}
268
\subsection{Simics}
255
Virtutech's Simics simulator can be compared to a Swiss-army knife for operating system debugging.
269
Virtutech's Simics simulator can be compared to a Swiss-army knife for operating system debugging.
256
This proprietary piece of software was available to us under an academic license for free.
270
This proprietary piece of software was available to us under an academic license for free.
257
 
271
 
258
Simics can be set to simulate many different configurations of many different machines.
272
Simics can be set to simulate many different configurations of many different machines.
Line 293... Line 307...
293
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
307
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
294
LMA equal to VMA. People from the Ski mailing list had tried to help us but our repeated problem report didn't
308
LMA equal to VMA. People from the Ski mailing list had tried to help us but our repeated problem report didn't
295
make it far enough for the HP to fix or at least clarify the issue. Finally, we adopted a workaround implemented by {\JJ}
309
make it far enough for the HP to fix or at least clarify the issue. Finally, we adopted a workaround implemented by {\JJ}
296
that simply swaps LMA and the program entry point in the kernel ELF image.
310
that simply swaps LMA and the program entry point in the kernel ELF image.
297
 
311
 
298
\subsection{VMware}
312
\subsection{VMware} VMware is the only virtualizer we have used in
299
VMware is the only virtualizer we have used in HelenOS development. It virtualizes the ia32 host machine.
313
HelenOS development. It virtualizes the ia32 host machine. Since VMware
300
Since VMware version 5.5, we made use of its possibility to run the guest system (i.e. HelenOS) on multiple processors.
314
version 5.5, we made use of its possibility to run the guest system
-
 
315
(i.e. HelenOS) on multiple processors. VMware has no support for
301
VMware has no support for debugging but is very useful for compatibility and regression testing because
316
debugging but is very useful for compatibility and regression testing
302
it's closest to the real hardware. VMware, being a virtualizer, is also the fastest of all the virtual environments
317
because it's closest to the real hardware. VMware, being a virtualizer,
303
we have utilized.
318
is also the fastest of all the virtual environments we have utilized.
304
 
319
 
305
 
320
 
306
\section{Authoring tools}
-