Re: [ECOS] synthetic cygwin target ?

[Bart Veer <bartv at redhat dot com>]

>>>>> "John" == John Gumb <JGumb@Ridgeway-Sys.com> writes:

    John> Hi,
    John> Would it be possible to produce a synthetic cygwin target ?
    John> Given how useful the synthetic linux target seems for
    John> testing, having this available under NT would provide an
    John> even more convenient environment.

    John> For fun, I tried an ecosconfig linux under cygwin and tried
    John> a make. The build falls over compiling
    John> syscall-i386-linux-1.0.S which I guess is to be expected !

I suspect this would be very hard, although I am by no means a Windows
expert. The issues to be resolved would include the following:

1) eCos uses functionality like constructor priority ordering that
   require fairly advanced object and image formats. Right now that
   means ELF, which is of course the default format for Linux systems.
   Windows uses PE, which I believe is derived from the old COFF
   format although I do not know exactly what extensions and other
   changes Microsoft have made. Certainly COFF is not powerful enough
   to support things like constructor priority ordering - at least, I
   cannot think of any simple implementation.

   So a first step would be to look into object file formats and see
   what is possible under Windows.

2) when using the synthetic target eCos is not linked directly with
   any Linux libraries, not even glibc. If the eCos application was
   linked with glibc then you would end up with linker clashes, e.g.
   both the eCos C library and glibc would attempt to define fopen().
   Clearly that is not going to work very well. Under Windows, the
   equivalent would be an executable that makes no use of any dlls
   or other Windows libraries whatsoever. I have no idea whether it is
   actually possible to create Windows executables that are not linked
   with any Windows libraries. Even cygwin applications are linked
   with the cygwin dll, and a quick look at the cygwin sources
   suggests that that in turn loads users32.dll, advapi.dll, and other
   libraries.

   Figuring out what is possible here would require detailed knowledge
   of exactly how Windows starts up new applications.

3) eCos would need to make system calls for things like brk(),
   write(), and gettimeofday() (or whatever the equivalent is for
   Windows). Under Linux figuring out this stuff is easy: a quick look
   at the kernel or glibc sources will tell you that for x86 this
   involves executing an int 0x80 trap with various parameters pushed
   on the stack, and the return values will be pretty obvious as well.
   There must be some equivalent under Windows, since you will need to
   use an int trap instruction to switch protection domains, but I do
   not know if the Windows system call interface is even documented.
   Normal Windows applications will not make direct system calls,
   instead they go via system-supplied dlls.

   There are other problems like the use of write(1, ...) to send
   output to the console. This is not a problem for Linux because
   applications always have a console, but I do not how well that
   would work for Windows.

4) there would also have to be some sort of support for interrupting
   a process. Right now this is used for clock interrupts, but in
   future it will be used for other I/O facilities as well. Unix
   systems have the concept of signals which provide the required
   functionality, I do not know what is possible under Windows.

There are also issues to worry about like variations between NT, 2000,
W95, W98, ...

So a synthetic target port to Windows may or may not be possible - I
do not know enough about Windows to be sure. Certainly it would be a
very large amount of work, and I suspect that there is little code in
the existing synthetic target HAL that could be re-used. Instead it
should probably be treated as a completely new port. 

Bart