6.1. Correction of compilation problems

Native C compiler

As stated in \xa4 4., page 8, binaries made by native and TenDRA compilers are interoperable. So a straightforward method to bypass a problem with TenDRA in DRA-NAT mode is to compile the ``guilty'' source file with the native compiler. This method has been used in cases where tcc lacked a feature, e.g. assembly language inlining, or when a bug in the code generated by tcc was identified but not yet fixed.

Source code modifications

In some cases, minor changes were applied to a source file (under #ifdef __ANDF__ conditions) when code rewriting was necessary to avoid a problem. Example: function f() is defined with no argument but is called sometimes with one argument in original source; the revised source will be:

int f() { }
/* .... */
#ifndef __ANDF__
	f(1);
#else
	f();
#endif

In other cases, we had to modify some Makefiles. In the DRA-NAT build, this was necessary for sources which contained assembly instructions for example (or included a header file which used the same feature). When building the libraries and commands, the relevant Makefiles were modified. When building the kernel, a more elegant method has been used: a ''rulefile'', included by all the Makefiles, has been modified to check, prior to compiling a .c file, if a file with the same name plus a specific suffix .NATIVE existed. If so, the native compiler was called. In addition, shell scripts were written to create lists of source files, which were dependent on header files known to contain assembly code (or #pragma pack), and to create the .NATIVE files according to these lists.

All these modifications on source files and Makefiles were done through a patch procedure:

• In order to patch a file, from the WORK tree, two copies of the file are made in a patch tree, one for modifications and the other for keeping the reference version.

• Then the initial file, usually a link into the source tree, is replaced by a link to the copy for modifications.

• Once this has been done, the initial file can be modified, while the initial version of the file is saved.

6.2. Identification of TenDRA built object files

In order to control the elements of the systems which were built in DRA-NAT mode, it was helpful to insert a special signature in object files created by the TenDRA compiler. An ident directive has been added to the assembly files generated by the TenDRA compiler, with the following pattern:

/andf/bin/trans386: (ANDF) 3.0 03/22/95

Such a pattern can be extracted by mcs or strings commands from binary files (executables and libraries) in order to control a posteriori the number of modules actually compiled by the TenDRA technology.

The file we modified in the TenDRA source delivery is the src/installer/trans386/trans.c file, and the change we made is located in the main() function:

init_all();

if (diagnose)
	out_diagnose_prelude();
TRASH d_capsule();

/* change start */
outs(".ident \"@(#)/andf/bin/trans386:   (ANDF) 3.0 03/22/95\"");
outnl();
/* change end */

while (weak_list)
	/* ... */

6.3. Kernel and shared libraries

Configuring the DRA-NAT kernel for actual hardware

The normal way to build a kernel is to create, from the set of object files built for the kernel part of the system, a kernel which is not targeted to any particular hardware. Then, the system must be packaged on a tape and floppies, in order to be installed. An installation procedure would then be used to load the system and interactively configure the generic kernel to the actual hardware. However, going all the way through this procedure would have required a lot of time and disk space.

We preferred to use a more simple and incremental way of building and configuring a new kernel:

• We dedicated a development machine for the kernel testing.

• We copied the /etc/conf tree into the ``MACH'' tree of DRA-NAT build. This tree holds the kernel binary components and the kernel configuration files.

• We replaced (partially or totally) the original binaries by their DRA-NAT version.

• We then rebuilt a kernel, with the idbuild command.

  Note that the idbuild command is sensitive to the environment variables defining the current build ``MACH'' tree (ROOT and MACH variables).

Progressive switching from native to DRA-NAT kernel

The method described above has proven very useful for easy fault isolation in case of a system crash.

Kernel components are divided into two parts: those parts of the base kernel (/stand/unix) and those dynamically-loaded (from /etc/conf/mod.d). We started by replacing only one, non-critical, component of the kernel. Then, we replaced some dynamically-loaded modules by their DRA-NAT version. We continued by replacing other base kernel modules and concluded with the remaining dynamically-loaded modules. More than ten intermediate kernels were built and exercised during this process.

Prior to exercising these kernels, emergency recovery floppies were made. They could be (and have been) used to repair manually the hard disk stand or root file systems when the normal boot process from the hard disk failed.

In order to switch to a new kernel, built in $ROOT/$MACH/etc/conf/cf.d/unix, it has to be copied into /stand (for example under the name unix.dranat). The new dynamically-loaded kernel modules, built in the $ROOT/$MACH/etc/conf/modnew.d directory, have also to be moved to the /etc/conf.d/mod.d directory in order to be loaded at the next system reboot. This latter operation should be done while the system is quiescent, i.e. after bringing it in single user mode and just before rebooting. To boot the alternative base kernel, the boot sequence is interrupted and an alternate kernel name is supplied by means of the KERNEL=name command.

Switching from native to DRA-NAT shared libraries

For exercising a shared library made during the DRA-NAT build, e.g. the dynamically loaded libc, relevant files in /usr/lib and /usr/ccs/lib were replaced by links to either the reference or the DRA-NAT versions of them. Care must be taken with these links, as shown by an example in \xa4 7.4, page 19.

6.4. VSX4 validation

Installing VSX4 and building tests for NAT-NAT & DRA-NAT systems validation

The VSX4 test suite is a rather large and complex application. Before actually running the tests, a number of steps have to be performed:

• We loaded the VSX4 test suite on a local disk which we added on one of the machines. Some hardware and system configurations were also needed in order to satisfy the VSX4 requirements.

• We configured the VSX4 test suite in order to provide it with the actual description of the system. This configuration had to be tuned while executing VSX4 on the native system, since for some parameters we did not have enough information on the system to make the right choice.

• We installed the VSX4 test suite, which consisted of the compilation of the tools VSX4 needed for executing the tests and for reporting on them.

• We built the VSX4 test suite, which consisted in producing the actual executable code for each test to be executed.

At this point, we were able to execute the tests on the native system to obtain reference results against which the DRA-NAT system would be compared.

For exercising the DRA-NAT build, we duplicated the tree which contained the executable tests (TESTROOT) and created a new directory to contain the results of build and execution steps. We customized the VSX4 build configuration file to use the TenDRA compiler in DRA-NAT mode and the commands/libraries built in the DRA-NAT phase, and we rebuilt the tests. Prior to reruning them, the configuration file for VSX4 execution was changed in a way similar to the build configuration file; note that the execution of some tests consists in performing a compilation.