This is the mail archive of the ecos-discuss@sourceware.org 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]
Other format: [Raw text]

RE: ARM EABI port / static constructor priority removal


> And also needs to be run _after_ the kernel code, but potentially
> before the libc code (which may reference the RTC), etc.etc.  It's just not
> feasible while retaining modularity which is far more valuable.

If it were written in C, there's still a way to do it, and it doesn't require
static constructor init ordering.
 
> Not really. In cyg_type.h CYG_INIT_APPLICATION is defined, and
> priorities
> 60000 up to 65534 are free for application use.
> 
> Arguably not with a reserved range for application use.

What if your code needs to do something in between one of the OS startup
steps?  This statement makes the assumption that the application and kernel
code are really separate, which is sometimes not a very clearly defined line
in eCos.  Presumably, one could argue that you shouldn't be doing anything
outside of the 'allowed' range by definition, but see next section...

> It's potentially feasible to create a section (not .ctors, something
> eCos-specific) that contains a list of tuples - a priority number and a
> function pointer. But then a) the list needs to be sorted at runtime
> which
> is very bad; and b) it seems very much that we're just swapping one
> extension for another.

Or they could be a set of ordered singletons in a startup file or something
equivalent.  Of course, this precludes one from writing a driver outside of
the tree and having it called in between steps.
 
> It's not the best solution, but it may be the least worst.

I guess it depends on how much one considers relying on non-portable compiler
specific behavior bad or not.  It's not part of ARM EABI officially, and had
CodeSourcery not decided to implement it, I would've had to do something
different to get EABI to work.  My point is not that it doesn't work as is,
but rather, that it's a self imposed limitation that there are portable ways
to solve.

If no one else wants to pursue it, I have to leave it as is though.

--Chris

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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