[ECOS] initialization priority workaround

[ECOS] initialization priority workaround

[James Robertson]

Hi,
I'm building eCos using gcc 2.8.1. Yes, this gcc doesn't support the 
initialization priority feature that eCos uses for constructor ordering. 
Unfortunately, this is a custom modified gcc, and I'm not able to upgrade to 
2.95 at this time. I've written a perl script to reorder the __CTOR_LIST__ by 
hand, but I was wondering if there were any better workarounds. Did you have any 
workaround before you put the constructor ordering in gcc?

James

Re: [ECOS] initialization priority workaround

[Jonathan Larmour]

James Robertson wrote:
> 
> Hi,
> I'm building eCos using gcc 2.8.1. Yes, this gcc doesn't support the
> initialization priority feature that eCos uses for constructor ordering.
> Unfortunately, this is a custom modified gcc, and I'm not able to upgrade to
> 2.95 at this time. I've written a perl script to reorder the __CTOR_LIST__ by
> hand, but I was wondering if there were any better workarounds. Did you have any
> workaround before you put the constructor ordering in gcc?

We hacked the linker script to manually order the constructors in the
__CTOR_LIST__ by matching the various object files the constructor symbols
came from. Like so (from the old code):

#ifdef CYG_KERNEL_USE_INIT_PRIORITY
    __CTOR_LIST__ = .;
    KEEP(*(SORT(.ctors*)))
    __CTOR_END__ = .;
    __DTOR_LIST__ = .;
    KEEP(*(SORT(.dtors*)))
    __DTOR_END__ = .;
#else
    __CTOR_LIST__ = .;
    *sched.o(.ctors*)
    *clock.o(.ctors*)
    *thread.o(.ctors*)
    *(.ctors*)
    __CTOR_END__ = .;
    __DTOR_LIST__ = .;
    *(.dtors)
    __DTOR_END__ = .;
#endif

To be honest, your perl script is probably the best thing in the absence of
the compiler feature.

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