[rtems-users] C++ Virtual Functions

[Smith, Gene]

Sergei Organov wrote, On 2/3/2005 8:38 AM:

> "Smith, Gene" <gene.smith at siemens.com> writes:
> 
> 
>>Sergei Organov wrote, On 2/2/2005 12:10 PM:
>>
>>
>>>"Smith, Gene" <Gene.Smith at siemens.com> writes:
>>>
>>
>>>>I am having some problems running code containing C++ virtual
>>>>functions in rtems. When the code tries to branch to a virtual
>>>>function address using "bctrl" instruction, the address (in ctr) is
>>>>way out of range and results in a machine check exception.
>>>>
>>>>Is there anything I need to do special in rtems for virtual functions to
>>>>work? Is anyone using virtual functions, pure or impure, in rtems? I am
>>>>still using rtems 4.6.1 and my ppc40x-derived bsp.
>>>
>>>Besides what others have already suggested to check for, it could be the
>>
>>>case that you call a virtual member function of a static or global
>>>object for which constructor hasn't been invoked (yet). In this case
>>>virtual table pointer in the object isn't initialized. Global
>>>constructors are invoked by special startup code so you need to check if
>>>this code is linked in and executed. Check for .ctors section in the
>>>executable as well.
>>
>>Yes, that is what I just concluded in my previous post to this thread.
>>I could see *no* .ctors or .dtors sections in my original output file.
>>The .ctors and .dtors sections were supposedly placed into the .text
>>section (see the attached linkcmds on previous msg). I then moved them
>>out of .text into their own sections following .got2 (as shown in
>>referenced example linkcmds, psim and motorola) and now I do see the
>>sections .c(d)tors in the output following .got2. However, I still
>>don't seem to see any initialization (construction) of the global
>>object in question (its constructor is never hit when a breakpoint is
>>put on it).
> 
> 
> The code that calls constructors doesn't in fact use .ctors section in
> any way, it uses __CTOR_LIST__  and probably __CTOR_END__ symbols that
> seem to be correctly defined by your linker script, so moving all that
> from .text to separate .ctors won't help.
> 
> Most probably you don't link in correct C++ startup code or somehow it's
> not called. There are guys on the list that know much better than me how
> C++ startup code is linked in and invoked in RTEMS. I can't tell out of
> my head as for historical reasons I do it manually in my projects, not
> using RTEMS standard ways. I.e., I have my own routine that calls all
> the functions put into the table referenced to by __CTOR_LIST__ and call
> it before main().

I went back a read everything I could find on this list regarding this
and several people have reported this problem. The only one who reported
a resolution did like you and wrote their own initializer (Phil Torre).
However there was a lot of discussion about "eabi" that got into the
ctor init and pointed out that it occurs in a call to _init() in
_Thread_Handler when __USE_INIT_FINI__ is defined. The _init() call
occurs on my system as described which in turn calls etext and
eventually __do_global_ctors_aux__ but I never see any constructors
actually called before _init() returns. I assume it is supposed to call
the constructors for any globally or statically defined c++ objects
somewhere inside the _init() call?  Also, are these c++ objects supposed
to be in the .bss section?
-gene