This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: synthetic cygwin target ?


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,
GetProcAddress, 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]