On 19/11/2015 2:06 AM, Aurelio Remonda wrote:
> Having an optional function that could be called prior to the construction of
> any global
> objects would be very useful.
> This is being discussed in the C++Embedded mailing list, in this thread:
> http://www.open-std.org/pipermail/embedded/2014-November/000226.html
I do not see a compelling list of reasons in the thread. The BSP and
driver initialisation APIs should manage hardware initialisation.
In the specific case of using global constructors in embedded real-time
C++ I found there is little you can assume as valid other than a
constructor call being made. I first used global objects and static
constructors in the early '90s with cfront to implement a linkerset type
functionality. The constructor did little more than add objects to a
list so code called from main could iterate over the list and do as it
needed. I suspect this two stage initialisation is a common pattern for
portable code. If you architect embedded applications with more things
happening in the constructors you need to manage this in your design.
The obvious issue is constructors do not return errors so at some point
in time you need to check for errors at some point and this leads to the
question of why not perform the initialisation then. Throwing exceptions
buys you nothing because you cannot catch them.
> For example, we would like to use this function to set an error handler for
> operator new, so that the handler is called if we run out of memory during
> global objects construction.
What happens in Linux or FreeBSD if you have a global constructor
attempt to new the entire address space?
I would hope our standard method of handling this type of error was
providing a consistent experience compared to other operating systems.
> This patch adds a pre_global_ctors function which is called right before the
> construction of global objects. The default implementation of this function
> is empty,
> and the function itself is declared with the 'weak' linker attribute.
> Users can then provide their own implementation of pre_global_ctors, which
> will override
> the default one.
>
> Any feedback or suggestions is welcome.
I prefer we investigate and exhaust a standards base approach first
before adding any thing extra. I am concerned it complicates and already
complex area and when you add newlib re-entrant code and locks plus TLS
support it gets more complex. The simple use cases are fine, it is any
abuse that makes it complex and the RTEMS projects has to support all cases.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
