[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rtems-users] C++ Virtual Functions



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

"Smith, Gene" <gene.smith@siemens.com> writes:


Sergei Organov wrote, On 2/2/2005 12:10 PM:


"Smith, Gene" <Gene.Smith@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