C++ static constructors and SMP

[Gedare Bloom]

On Oct 19, 2013 9:09 PM, "Chris Johns" <chrisj at rtems.org> wrote:
>
> On 20/10/13 11:30 AM, Gedare Bloom wrote:
>>
>> Hi,
>> I'm not a C++ expert (You might get better advice from the GCC
>> community.) but I'm pretty sure initializing static constructors is
>> done by the compiler, so the relevant code would be found in gcc
>> located with either .init/.fini, .init_array/.fini_array or
>> .ctors/.dtors. RTEMS just puts them in the right place via linkcmds
>> file. I guess the C++ runtime startup is not honoring some assumptions
>> made about the static constructors.
>>
>
> This is a bug in RTEMS. The cores need to wait until the constructors
have run. I have not had time to take a closer look because Joel keeps
bringing me beer ... which I do not mind.
>
Have a pint for me. I assumed the c/c++ runtime initialization ran serially
with other bootstrap/initialization on the bootup core. Guess I have not
looked closely enough! I would think rtems initialization should "finish"
before the application starts? Otherwise lots of badness could happen...
-Gedare

> Chris
>
>
>> -Gedare
>>
>>
>>
>>
>>
>>
>> On Fri, Oct 18, 2013 at 2:07 PM, Stephen Tether
>> <tether at slac.stanford.edu> wrote:
>>>
>>> Hi, all. At SLAC we've just started to experiment with the ML1 SMP
version
>>> of RTEMS 4.11.0.1 on the Zynq. We're having a problem with some
statically
>>> allocated C++ objects: the constructors are not being called before the
>>> first calls to the objects' member functions, which eventually results
in a
>>> data abort due to a null pointer. Sometimes the constructors *are*
called
>>> first, sometimes they are called too late and sometimes they don't get
>>> called at all before the abort. How are static constructors handled in
this
>>> version of RTEMS and which source files do I need to look at?
>>>
>>> - Steve Tether
>>> _______________________________________________
>>> rtems-devel mailing list
>>> rtems-devel at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20131019/4a31b1dd/attachment-0001.html>