[ECOS] Coff format on i386

[ECOS] Coff format on i386

[Hansjörg Petriffer]

Hello,

at the moment I'm testing to compile eCos with coff format and until now I
have changed only a few lines.

For example into the devtab.h I have inserted and changed

#if (defined __i386__) 
#define SECTION_DEVTAB
#else
#define SECTION_DEVTAB __attribute__ ((section(".devtab")))
#endif (defined __i386__) 

#define DEVTAB_ENTRY(_l,_name,_dep_name,_handlers,_init,_lookup,_priv)  \
cyg_devtab_entry_t _l SECTION_DEVTAB = {          \
   _name,                                                               \
   _dep_name,                                                           \
   _handlers,                                                           \
   _init,                                                               \
   _lookup,                                                             \
   _priv                                                                \
};


because it seems that the i386-coff doesn't support the
__attribute__((section(".devtab"))).
Than I had the problem that the i386 doesn't support alias. For testing
purposes I have changed a few commands which are used and then I have
compiled and linked a few of the test programs. 
This programs than I have converted with the i386-coff-objcopy -O binary to
a bin file and than I have written to a disk.
All the test programs that I have compiled are working in the same manner as
with elf format.
Can anyone say me if this is only fortunate coincidence or if this (coff
format) may be also possible with a few changes?


Thanks for any comment!

Hansjoerg

Re: [ECOS] Coff format on i386

[Bart Veer]

>>>>> "Hansjoerg" == =?iso-8859-1?Q?Hansj=F6rg Petriffer?= <iso-8859-1> writes:

    Hansjoerg> Hello,
    Hansjoerg> at the moment I'm testing to compile eCos with coff
    Hansjoerg> format and until now I have changed only a few lines.

    Hansjoerg> For example into the devtab.h I have inserted and changed

    Hansjoerg> #if (defined __i386__) 
    Hansjoerg> #define SECTION_DEVTAB
    Hansjoerg> #else
    Hansjoerg> #define SECTION_DEVTAB __attribute__ ((section(".devtab")))
    Hansjoerg> #endif (defined __i386__) 

    Hansjoerg> #define DEVTAB_ENTRY(_l,_name,_dep_name,_handlers,_init,_lookup,_priv)  \
    Hansjoerg> cyg_devtab_entry_t _l SECTION_DEVTAB = {          \
    Hansjoerg>    _name,                                                               \
    Hansjoerg>    _dep_name,                                                           \
    Hansjoerg>    _handlers,                                                           \
    Hansjoerg>    _init,                                                               \
    Hansjoerg>    _lookup,                                                             \
    Hansjoerg>    _priv                                                                \
    Hansjoerg> };

    Hansjoerg> because it seems that the i386-coff doesn't support the
    Hansjoerg> __attribute__((section(".devtab"))).

    Hansjoerg> Than I had the problem that the i386 doesn't support
    Hansjoerg> alias. For testing purposes I have changed a few
    Hansjoerg> commands which are used and then I have compiled and
    Hansjoerg> linked a few of the test programs. This programs than I
    Hansjoerg> have converted with the i386-coff-objcopy -O binary to
    Hansjoerg> a bin file and than I have written to a disk. All the
    Hansjoerg> test programs that I have compiled are working in the
    Hansjoerg> same manner as with elf format. Can anyone say me if
    Hansjoerg> this is only fortunate coincidence or if this (coff
    Hansjoerg> format) may be also possible with a few changes?

A combination of fortunate coincidence and test cases that do not do
as much checking as they should. 

In this particular example you are turning devtab entries into
ordinary data. As a consequence the table of devtab entries will be
empty, so any programs that attempt to open "/dev/whatever" will fail.
The same holds for network devices. C++ constructors will not get run
in priority order, so the system's various initialization routines may
run in a completely random order and it is anybody's guess just how
much of the system will be correctly initialized by the time main()
starts running.

For proper operation eCos requires an image format that supports an
arbitrary number of sections, unlike COFF which only has .text, .data
and .bss. In practice right now this means ELF.

Bart