Porting -- Adding support for other hosts
The initial development effort of the eCos synthetic target happened
on x86 Linux machines. Porting to other platforms involves addressing
a number of different issues. Some ports should be fairly
straightforward, for example a port to Linux on a processor other than
an x86. Porting to Unix or Unix-like operating systems other than
Linux may be possible, but would involve more effort. Porting to a
completely different operating system such as Windows would be very
difficult. The text below complements the eCos Porting Guide.
Other Linux Platforms
Porting the synthetic target to a Linux platform that uses a processor
other than x86 should be straightforward. The simplest approach is to
copy the existing i386linux
directory tree in the hal/synth
hierarchy, then rename and edit the ten or so files in this package.
Most of the changes should be pretty obvious, for example on a 64-bit
processor some new data types will be needed in the
basetype.h header file. It will also be necessary
to update the toplevel ecos.db database with an
entry for the new HAL package, and a new target entry will be needed.
Obviously a different processor will have different register sets and
calling conventions, so the code for saving and restoring thread
contexts and for implementing
longjmp will need to be updated. The exact way of
performing Linux system calls will vary: on x86 linux this usually
involves pushing some registers on the stack and then executing an
int 0x080 trap instruction, but on a different
processor the arguments might be passed in registers instead and
certainly a different trap instruction will be used. The startup code
is written in assembler, but needs to do little more than extract the
process' argument and environment variables and then jump to the main
linux_entry function provided by the
architectural synthetic target HAL package.
The header file hal_io.h provided by the
architectural HAL package provides various structure definitions,
function prototypes, and macros related to system calls. These are
correct for x86 linux, but there may be problems on other processors.
For example a structure field that is currently defined as a 32-bit
number may in fact may be a 64-bit number instead.
The synthetic target's memory map is defined in two files in the
For x86 the default memory map involves eight megabytes of read-only
memory for the code at location 0x1000000 and another eight megabytes
for data at 0x2000000. These address ranges may be reserved for other
purposes on the new architecture, so may need changing. There may be
some additional areas of memory allocated by the system for other
purposes, for example the startup stack and any environment variables,
but usually eCos applications can and should ignore those.
Other HAL functionality such as interrupt handling, diagnostics, and
the system clock are provided by the architectural HAL package and
should work on different processors with few if any changes. There may
be some problems in the code that interacts with the I/O auxiliary
because of lurking assumptions about endianness or the sizes of
various data types.
When porting to other processors, a number of sources of information
are likely to prove useful. Obviously the Linux kernel sources and
header files constitute the ultimate authority on how things work at
the system call level. The GNU C library sources may also prove very
useful: for a normal Linux application it is the C library that
provides the startup code and the system call interface.
Other Unix Platforms
Porting to a Unix or Unix-like operating system other than Linux would
be somewhat more involved. The first requirement is toolchains: the
GNU compilers, gcc and g++, must definitely be used; use of other GNU
tools such as the linker may be needed as well, because eCos depends
on functionality such as prioritizing C++ static constructors, and
other linkers may not implement this or may implement it in a
different and incompatible way. A closely related requirement is the
use of ELF format for binary executables: if the operating system
still uses an older format such as COFF then there are likely to be
problems because they do not provide the flexibility required by eCos.
In the architectural HAL there should be very little code that is
specific to Linux. Instead the code should work on any operating
system that provides a reasonable implementation of the POSIX
standard. There may be some problems with program startup, but those
could be handled at the architectural level. Some changes may also be
required to the exception handling code. However one file which will
present a problem is hal_io.h, which contains
various structure definitions and macros used with the system call
interface. It is likely that many of these definitions will need
changing, and it may well be appropriate to implement variant HAL
packages for the different operating systems where this information
can be separated out. Another possible problem is that the generic
code assumes that system calls such as
cyg_hal_sys_write are available. On an operating
system other than Linux it is possible that some of these are not
simple system calls, and instead wrapper functions will need to be
implemented at the variant HAL level.
The generic I/O auxiliary code should be fairly portable to other Unix
platforms. However some of the device drivers may contain code that is
specific to Linux, for example the PF_PACKET socket
address family and the ethertap virtual tunnelling interface. These
may prove quite difficult to port.
The remaining porting task is to implement one or more platform HAL
packages, one per processor type that is supported. This should
involve much the same work as a port to another processor running Linux.
When using other Unix operating systems the kernel source code may not
be available, which would make any porting effort more challenging.
However there is still a good chance that the GNU C library will have
been ported already, so its source code may contain much useful
Porting the current synthetic target code to some version of Windows
or to another non-Unix platform is likely to prove very difficult. The
first hurdle that needs to be crossed is the file format for binary
executables: current Windows implementations do not use ELF, instead
they use their own format PE which is a variant of the rather old and
limited COFF format. It may well prove easier to first write an ELF
loader for Windows executables, rather than try to get eCos to work
within the constraints of PE. Of course that introduces new problems,
for example existing source-level debuggers will still expect
executables to be in PE format.
Under Linux a synthetic target application is not linked with the
system's C library or any other standard system library. That would
cause confusion, for example both eCos and the system's C library
might try to define the
printf function, and
introduce complications such as working with shared libraries. For
much the same reasons, a synthetic target application under Windows
should not be linked with any Windows DLL's. If an ELF loader has been
specially written then this may not be much of a problem.
The next big problem is the system call interface. Under Windows
system calls are generally made via DLL's, and it is not clear that
the underlying trap mechanism is well-documented or consistent between
different releases of Windows.
The current code depends on the operating system providing an
implementation of POSIX signal handling. This is used for I/O
purposes, for example SIGALRM is used for the
system clock, and for exceptions. It is not known what equivalent
functionality is available under Windows.
Given the above problems a port of the synthetic target to Windows may
or may not be technically feasible, but it would certainly require a
very large amount of effort.