This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C++ Polymorphism problem MSP430 compiler



Hi,

The following code is failing to enter A::g(int a):

#define _VIRTUAL_B_

volatile int x;

class C {
public:
virtual void g(int a) = 0;
};

class B
{
public:
#ifdef _VIRTUAL_B_
virtual void h() = 0;
#else
void h() {};
#endif
};

class A : public B, public C
{
public:
void g(int a);
#ifdef _VIRTUAL_B_
void h() {}
#endif
};

void A::g(int a) {
x=a;
}

A aa;

int main()
{
C *p = static_cast<C*>(&aa);
p->g(3);

return 0;
}

 

The above is a simplification of what I am trying to achieve in my own application.

Commenting out the #define works. The problem would seem to be that if class A inherits two base classes, then the polymorphism does not work. I have checked this out with Microsoft C++ and it works fine. I would appreciate if someone (hopefully a TI compiler Guru) could  check this out for me. It also works if class B is changed to inherit C instead of A inheriting C directly.

Best regards

Martin Knott

Edinburgh, UK

I have Code Composer Studio Version: 6.1.0.00104, "CCS Product Branding" is

Version: 6.1.0.201502111100
Build id: N201502111100

Eclipse C/C++ Development Tools

Version: 8.5.0.201409172108

Eclipse GCC Cross Compiler Support

Version: 8.5.0.201409172108

I am using C++03 dialect (as embedded C++ does not support polymorphism).



  • Moving this to TI compiler forum for a faster response from the experts.
  • Martin Knott10 said:
    The problem would seem to be that if class A inherits two base classes, then the polymorphism does not work.

    How do you know it doesn't work?  Exactly how do you see it?

    Also show the version number of the compiler, which is different from the CCS version.  Please see this wiki article for details.

    Thanks and regards,

    -George

  • Hi George,

    Thank you for the prompt reply. The compiler version is TI v4.4.4. Yes, your summary of the problem is correct. The working version (only one of the base classes being abstract) steps in (with F5) to A::g(), whereas the non working version (both abstract base classes) steps over. With my larger application, it goes off to never-never-land, sometimes showing "thunk" something or other.

    I look forward to receiving further advise.

    Best Regards,

    Martin

  • I'm pretty sure this is a problem in the debugger.  It cannot handle stepping into polymorphic calls.  The function A::g does execute.  You can observe that by watching the value of x.  It changes from 0 to 3 as expected.  If you assembly step (menu selection Run | Assembly Step Into) enough times, you do finally get into A::g.  You see control pass through the thunk, then into A::g.  I submitted CCSIDE-2895 to the SDOWP system to have this problem investigated.  Feel free to follow it with the SDOWP link below in my signature.

    All that said, it is possible this is a problem in how the compiler generates the debug information for polymorphic function calls.  That may come out as part of the investigation.

    Thanks and regards,

    -George

  • Thanks George. Yes, I too eventually stepped through the thunk with the simple example. I have been away on holiday and have not had another chance to look at my original larger problem, which seemed to send my app off to a weird address resulting in the application hanging. So maybe my initial simplification does not properly reproduce the problem I was seeing. 

    The call stack is never fully populated. I am using a the built-in launchpad debug interface; would I be correct in saying that this would give me a less complete call stack than with a JTAG connection via a separate FET.

    Thanks,

    Martin

  • Martin Knott10 said:
    The call stack is never fully populated.

    I presume you watch the call stack grow and shrink in CCS.  This too could be a debugger problem.  While I don't know for sure, my guess is that CCS loses track of what call frames are on the stack as the odd function call through a thunk occurs.

    Thanks and regards,

    -George