[ECOS] synthetic cygwin target ?

[ECOS] synthetic cygwin target ?

[John Gumb]

Hi,

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

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

Cheers,

John Gumb
Software Engineer
Ridgeway Systems and Software
Tel +44  118 9381108 (direct dial)
Tel +44  118 9351111 (switchboard)
Fax +44  118 9354444
email jgumb@ridgeway-sys.com
web www.ridgeway-sys.com

Re: [ECOS] synthetic cygwin target ?

[Jesper Skov]

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

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

Yes, it's possible. To do it, you'll need to know how to map the
linux system calls into equivalent Windows calls. 

I think you'll probably only have to change vectors.S,
syscall-i386-linux-1.0.S, and the linker files.

Bart has put some comments in the arch files that explain what they
require from the platform HAL.

Jesper

Re: [ECOS] synthetic cygwin target ?

[Bart Veer]

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

Re: [ECOS] synthetic cygwin target ?

[Donnat Eric]

Bart Veer wrote:
> 
> >>>>> "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.
> 

An alternative would be to compile in elf-i386 and use a loader, or may-be
a post-link process to build a correct PE for the elf, either way
this may have impact on debugging ...

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

Any win32 is linked against at least kernel32.dll. The trick here is to
use kernel32 only in importing (when loading) few calls (LoadLibrary,
\x7f\x7fGetProcAddress, FreeLibrary) and bind other things dynamically

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

Of course there are traps on windowses, but they are dependant of the
release of the system + very few are known by reverse eng. ... So the
really only way is to use win32.

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

Console apps always have a console, but this is a bit different from
unix/linux. Don't think it is a major drawback.

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

Here it is, one of the major difficulty, is to find a way to get the
clock interrupt to work seamlessly as in linux. Some implementations
are possible on some platform (NT) but are impossible with others.
The most limitating thing would be W95. Of course, you can cheat on
the cygwin implementation to find something, but I think this is
very challenging if you don't have a deep knowledge of win32.

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

You're right.

> Bart

-- 
Eric DONNAT

Silicomp Research Institute
2 avenue de Vignate, 38610 Gieres, France.
Phone +33 476 63 48 85   Fax +33 476 51 05 32
http://www.ri.silicomp.com