[rtems-users] C++ Virtual Functions

[Smith, Gene]

Joel Sherrill <joel at OARcorp.com> wrote, On 2/3/2005 10:57 AM:

> Sergei Organov wrote:
> 
>>"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().
>>
> 
> 
> psim in the CVS tree and head of the 4.6 branch works for C++ and 
> exceptions.  The trick is in the linkcmds and bsp_specs.  If you get 
> those right, it should just work.
> 
> bsp_specs
> ==========
> The *startfile section needs to include ecrti, rtems_crti, and crtbegin.
> 
> The *endfile section needs to include crtend and ecrtn.
> 
> CHeck out psim/bsp_specs on the head of the 4.6 branch or the trunk.
> It looks different from the gen405/bsp_specs.
> 
> linkcmds
> =========
> Look for the .init and .fini sections and the CTOR/DTOR (caps) related
> sections.
> 
> --joel
> 

I think Sergei and Phil are saying this is probably the right way to go. 
However, I still have a bit of a problem. The rtems_crti.o file is 
flagged during link as not present. I found a rtems_crti.S in the 
libbsp/powerpc/shared  area but it is is not being assembled in my 
gen40x/helas403 hybrid bsp. I moved it into my bsp and assembled it 
along with my startup assembly file but ld still can't find it. Looks 
like it needs to be somewhere in the region of crtbegin.o to be found by 
ld. I suppose rtems_crti is important?
-gene