[ECOS] i386/Windows target?

[ECOS] i386/Windows target?

[Tom M. Yeh]

Like i386/Linux synthetic target, is there a Windows synthetic target under developing?

Regards,
Tom

Re: [ECOS] i386/Windows target?

[Bart Veer]

>>>>> "Tom" == Tom M Yeh <tomyeh@infoshock.com> writes:

    Tom> TGlrZSBpMzg2L0xpbnV4IHN5bnRoZXRpYyB0YXJnZXQsIGlzIHRoZXJlIGEgV2l
    Tom> uZG93cyBzeW50aGV0aWMgdGFyZ2V0IHVuZGVyIGRldmVsb3Bpbmc/DQoNClJlZ2
    Tom> FyZHMsDQpUb20=

When sending to a public mailing list such as ecos-discuss, please
mail in plain text rather than using any form of encoding. People use
a wide variety of mail readers and may have problems deciphering
messages like the above.

    Tom> Like i386/Linux synthetic target, is there a Windows
    Tom> synthetic target under developing?

I know nobody within Red Hat is working on this. I am not sure whether
it is even feasible.

When building an synthetic target application you cannot link with any
of the host libraries. For example you cannot link with any of the
Linux C library because that would define a function malloc() which
clashes with the eCos libc malloc() implementation.

However the synthetic target application must still be able to make
certain system calls such as read() and write() so that it can
interact with the outside world. There must also be a way of setting
up incoming timer events to fake up a hardware clock, handled by alarm
signals in the Linux synthetic target, and in the near future there
must be some equivalent of SIGIO for use with pipes. On Linux none of
this is particularly difficult: all the required system calls can be
made by executing 0x80 traps, and details such as which arguments go
into which registers are readily obtained from the kernel sources.

From my limited knowledge of Windows, everything tends to happen by
linking with various DLL's so there is a good chance of a name clash
somewhere along the way. Presumably at some point there is a system
call mechanism that goes via traps, but I do not know the details or
how things vary between the different varieties of Windows.

There are also problems related to executable file formats. Linux uses
ELF, which provides all the functionality required by eCos. I believe
Windows still uses COFF, or some variant thereof.

It might be possible to solve these problems, but I suspect it would
require a lot of work.

Bart Veer // eCos net maintainer

RE: [ECOS] i386/Windows target?

[Tom M. Yeh]

Thanks for your information. However, I wonder why eCos demands ELF. Can we
use the native compiler for Cygwin (i686-pc-cygwin-*)? Don't the PowerPC
version use another format?

Regards,
Tom M. Yeh

-----Original Message-----
From: ecos-discuss-owner@sourceware.cygnus.com
[ mailto:ecos-discuss-owner@sourceware.cygnus.com]On Behalf Of Bart Veer
Sent: Friday, June 02, 2000 12:53 AM
To: tomyeh@infoshock.com
Cc: ecos-discuss@sourceware.cygnus.com
Subject: Re: [ECOS] i386/Windows target?


>>>>> "Tom" == Tom M Yeh <tomyeh@infoshock.com> writes:

    Tom> TGlrZSBpMzg2L0xpbnV4IHN5bnRoZXRpYyB0YXJnZXQsIGlzIHRoZXJlIGEgV2l
    Tom> uZG93cyBzeW50aGV0aWMgdGFyZ2V0IHVuZGVyIGRldmVsb3Bpbmc/DQoNClJlZ2
    Tom> FyZHMsDQpUb20=

When sending to a public mailing list such as ecos-discuss, please
mail in plain text rather than using any form of encoding. People use
a wide variety of mail readers and may have problems deciphering
messages like the above.

    Tom> Like i386/Linux synthetic target, is there a Windows
    Tom> synthetic target under developing?

I know nobody within Red Hat is working on this. I am not sure whether
it is even feasible.

When building an synthetic target application you cannot link with any
of the host libraries. For example you cannot link with any of the
Linux C library because that would define a function malloc() which
clashes with the eCos libc malloc() implementation.

However the synthetic target application must still be able to make
certain system calls such as read() and write() so that it can
interact with the outside world. There must also be a way of setting
up incoming timer events to fake up a hardware clock, handled by alarm
signals in the Linux synthetic target, and in the near future there
must be some equivalent of SIGIO for use with pipes. On Linux none of
this is particularly difficult: all the required system calls can be
made by executing 0x80 traps, and details such as which arguments go
into which registers are readily obtained from the kernel sources.

From my limited knowledge of Windows, everything tends to happen by
linking with various DLL's so there is a good chance of a name clash
somewhere along the way. Presumably at some point there is a system
call mechanism that goes via traps, but I do not know the details or
how things vary between the different varieties of Windows.

There are also problems related to executable file formats. Linux uses
ELF, which provides all the functionality required by eCos. I believe
Windows still uses COFF, or some variant thereof.

It might be possible to solve these problems, but I suspect it would
require a lot of work.

Bart Veer // eCos net maintainer

Re: [ECOS] i386/Windows target?

[Bart Veer]

>>>>> "Tom" == Tom M Yeh <tomyeh@infoshock.com> writes:

    Tom> Thanks for your information. However, I wonder why eCos
    Tom> demands ELF. Can we use the native compiler for Cygwin
    Tom> (i686-pc-cygwin-*)? Don't the PowerPC version use another
    Tom> format?

The configure triplet for powerpc specifies eabi, but this is just ELF
with some minor additions/tweaks/clarifications.

eCos does not specifically demand ELF, in that there is nothing in the
source code which knows about ELF executables. However it does require
the following:

1) constructor priority ordering. This is most easily implemented by
   putting the static objects into appropriately numbered linker
   sections, and sorting them in the linker script. So you need an
   image format which supports lots of linker sections.

2) linker garbage collection, also known as selective linking. This is
   most easily implemented by putting every function and variable into
   its own linker section. Strictly speaking this is not absolutely
   necessary, but without it the final executables will be
   significantly bigger than necessary. Arguably this is not so much
   of a problem when using a synthetic target.

3) weak symbol support.

ELF can handle all of this. Older image formats typically cannot, e.g.
there are likely to be strict limits on the number of linker sections
you can create. I do not know exactly what the limitations are in the
image format currently used by Windows, so I cannot comment further.

Bart Veer // eCos net maintainer

Re: [ECOS] i386/Windows target?

[Jonathan Larmour]

Bart Veer wrote:
> 
> eCos does not specifically demand ELF, in that there is nothing in the
> source code which knows about ELF executables. However it does require
> the following:
> 
> 1) constructor priority ordering. This is most easily implemented by
>    putting the static objects into appropriately numbered linker
>    sections, and sorting them in the linker script. So you need an
>    image format which supports lots of linker sections.
> 
> 2) linker garbage collection, also known as selective linking. This is
>    most easily implemented by putting every function and variable into
>    its own linker section. Strictly speaking this is not absolutely
>    necessary, but without it the final executables will be
>    significantly bigger than necessary. Arguably this is not so much
>    of a problem when using a synthetic target.
> 
> 3) weak symbol support.

4) Handling of arbitrary output section names. Some object formats only
permit a particular list of names: .text, .data, etc. rather than arbitrary
ones.

> ELF can handle all of this. Older image formats typically cannot, e.g.
> there are likely to be strict limits on the number of linker sections
> you can create. I do not know exactly what the limitations are in the
> image format currently used by Windows, so I cannot comment further.

 As I understand it,  Windows uses PE, which is based on COFF. COFF does
not support any of the features 1-4 above. (ECOFF supports 3 and 4 IIRC,
but that's no use to PE). Therefore PE cannot support the features required
by eCos at present.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] i386/Windows target?

[Ian Lance Taylor]

   Date: Fri, 2 Jun 2000 14:31:03 +0100
   From: Bart Veer <bartv@redhat.com>

   The configure triplet for powerpc specifies eabi, but this is just ELF
   with some minor additions/tweaks/clarifications.

A small clarification.  The PowerPC EABI is ELF, under any reasonable
definition of ELF.  The EABI has a different name because it is not
quite the same as the version of ELF used on PowerPC Solaris, and it
would be confusing to have two different standards named PowerPC ELF.

Ian