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

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



"Smith, Gene" <gene.smith@siemens.com> writes:
> Sergei Organov wrote, On 2/3/2005 9:45 AM:

[...]

> 
> PODs?

Plain Old Data. I.e., structs/classes that has no virtual functions and
constructors. Strictly speaking, having inheritance or references as
members also makes a struct/class non-POD, but probably you'll be able
to put and object of such class into ROM anyway.

> Anyhow, thanks for the code. I put it in my init.c and I now see some
> constructors being called by it. However, for some reason, I don't see
> the constructor for the class with the virtual function that I am
> wanting to be called. The class variable is declared static and it's
> constructor is in the the same cpp file. When I dump the object for
> the cpp file I see a .ctor section of size 4 and the constructor of
> interest is in a ".gnu.linkonce.t..." type of section. But the address
> of the constructor never seems to make it to the final .ctor table
> since when it goes through your code it never calls the constructor of
> interest.

Try to generate map file by providing -Wl,-Map,main.map to the final gcc
invocation that links the application, then find where this section
(.ctors) went by searching for it in the resulting "main.map" file.

> I also changed my linkcmds file (in the libbsp area) as you show. All
> I did was re-install rtems and it put linkcmds to the right place in
> the install area, /opt/rtems-4.6. Then I forced a relink of my app.
> That seem like enough but maybe I need to make clean all, make install
> rtems and rebuild clean my app. Takes a while but I will do it now.

What you did should in fact be enough. Try the above suggestion.

Actually, however, after you get all of you constructors called using
this custom method, I'd suggest you to try to fix things so that
standard RTEMS way of invoking constructors (through gcc-provided
routines) work. You probably will have less problems using this method
in the long term.

-- 
Sergei.