This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: ARM EABI port / static constructor priority removal
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: Chris Zimman <czimman at bloomberg dot com>
- Cc: Andrew Lunn <andrew at lunn dot ch>, ecos-discuss at sourceware dot org
- Date: Wed, 02 Apr 2008 15:19:49 +0100
- Subject: Re: [ECOS] ARM EABI port / static constructor priority removal
- Openpgp: id=A5FB74E6
- References: <F31C1582037F5041B0CD525FD870AE6A774244@ny2545.corp.bloomberg.com> <20080326180616.GA5705@lunn.ch> <F31C1582037F5041B0CD525FD870AE6A774245@ny2545.corp.bloomberg.com> <20080326181817.GB5705@lunn.ch> <F31C1582037F5041B0CD525FD870AE6A774246@ny2545.corp.bloomberg.com> <20080326183202.GC5705@lunn.ch> <F31C1582037F5041B0CD525FD870AE6A774247@ny2545.corp.bloomberg.com> <20080326185037.GD5705@lunn.ch> <F31C1582037F5041B0CD525FD870AE6A774248@ny2545.corp.bloomberg.com>
Chris Zimman wrote:
>> Also ugly. You break the nice packing model. Say i have an out of tree
>> package, a device driver for the wall clock on my hardware. The
>> current code allows my code to have a static initializer with priority
>> that is after I2C is up and running and it is totally independent of
>> the in tree code.
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.
>> I don't need to modify the in tree code at all. The
>> linker sorts it all out. Your suggestion would force me to modify the
>> in tree list of constructors.
>
> With what you're talking about here, you'd have to modify cyg_type.h anyway
Not really. In cyg_type.h CYG_INIT_APPLICATION is defined, and priorities
60000 up to 65534 are free for application use.
> if you want to add a new init priority unless you want to keep it private,
> which is kind of bogus. With the current model anyhow, you *have* to be
> aware of the ordering in cyg_type.h and known what values are assigned to
> which constructors. That's pretty ugly in and of itself.
Arguably not with a reserved range for application use.
> There's also no inherent reason you would have to modify in tree code to
> accomplish what you're suggesting. Sections can be created for just that
> purpose. Even enforcing startup ordering rules is pretty straight forward
> that way.
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.
Although reworking our abstraction to _permit_ this mode of operation
(without requiring it for GCC users) might make eCos more portable to other
compilers by making this sort of thing possible.
>> The same could be said for application code. My application wants a
>> static constructor called after the OS is up an running, but before
>> main() is called. Should i modify the OS to list my application
>> constructors?
>
> It's not about the use of static constructors in general, it's about relying
> on non-portable behavior with respect to using them (construction ordering).
It's not the best solution, but it may be the least worst.
Jifl
--
eCosCentric Limited http://www.eCosCentric.com/ The eCos experts
** Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv> **
** April 15-17 2008, Booth 3012, San Jose McEnery Convention Center **
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------ Opinions==mine
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss