CCS/66AK2H12: CCS debugging objects derived from virtual base class

Mike Dannhardt said:

I am having trouble debugging objects that are of a class derived from an abstract base class, i.e. containing pure virtual functions. If I create a new instance of the derived object and try to view it in the Expressions, I get a message that says: "Error: cannot load from non-primitive location".

Is this problem with a program on the a Cortex-A15 core using the GCC ARM compiler, or a program on a C66 core using the TI C6000 compiler?

There was the thread CCS/CCSTUDIO-SITARA: C++ code, Cannot see variables class in debugger on what might be the same problem symptoms when the GCC ARM compiler was used, but there wasn't a known work-around to the problem in the referenced thread.

Not sure if you are encountering the same problem, or a different problem.

Hi Chester. Sorry I missed your reply for several days. Yes I am on the ARM compiling w/ GNU v4.9.3. The linked E2E discussion thread you reference seems to be discussing the same bug. I hope someone from TI chimes in with a status update or information on how to work around the problem.

Do you think compiling with GNU 6.3.1 would solve the problem? [I quickly thought I'd try it but my project does not compile. I am using the NDK 2.25.1.11 and I get multiple defines for LITTLE_ENDIAN and struct timeval. I didn't see an easy fix so I backed off for the moment].

Hi
How I can change app_port0_phy_addr in ak2h12?

Mike Dannhardt said:

Do you think compiling with GNU 6.3.1 would solve the problem?

I would try with a non SYS/BIOS program, but don't have access to the required hardware at the moment (will be able to try at the weekend).

Mike Dannhardt said:

I quickly thought I'd try it but my project does not compile. I am using the NDK 2.25.1.11 and I get multiple defines for LITTLE_ENDIAN and struct timeval. I didn't see an easy fix so I backed off for the moment

From memory, when I last tried to take SYS/BIOS programs developed with the GNU 4.9.4 compiler got errors when attempted to use GNU 6.3.1 but can't remember the exact details. I think GNU 6.3.1 comes with include files which conflicted with SYS/BIOS include files.

Mike Dannhardt said:

Do you think compiling with GNU 6.3.1 would solve the problem?

I ported the previous bare-metal example of the problem to run on the Cortex-A15 core of a EVMK2H. Using CCS 7.3.0.00019 running under Windows.

When the program was compiled for the Cortex-A15 using GNU v4.9.3 the CCS 7.3 debugger fails to display the values of the m_pMaster or m_pMasterPlat class variables:

Compiling the Cortex-A15 program using GNU v6.3.1 and the CCS 7.3 debugger still fails to display the value of _pMaster or m_pMasterPlat class variables:

I.e. changing from GNU v4.9.3 to v6.3.1 doesn't fix the problem.

The project used for the Cortex-A15 core is attached. 66AK2H14_GCC_class_variables.zip There are separate build configurations for GNU compiler versions v4.9.3 and v6.3.1.

The same test program was compiled for a C66 core, using TI compiler v8.1.4. The CCS 7.3 debugger correctly displays the value of _pMaster or m_pMasterPlat class variables when the program is run on a C66 core:

The example for the C66 core is attached 66AK2H14_C66_class_variables.zip

Not sure if the problem is how the ARM GNU compiler is encoding the debug information, or how CCS 7 is interpreting the debug information.

Chester Gillon said:

Not sure if the problem is how the ARM GNU compiler is encoding the debug information, or how CCS 7 is interpreting the debug information.

The ARM GNU compiler installed by CCS has an arm-none-eabi-gdb executable, and CCS 7.3 includes the XDS GDB Agent.

The CCS 7.3 XDC GDB Agent doesn't appear to support a Cortex-A15, since when attempted to use gdb_agent_console with a board data file for a 66AK2H14 got an "No CPUs that support GDB are defined in configuration file" error.

Therefore, investigated with a Cortex-A8 in an AM3352:

1) In CCS 7.3 created a project the the test program using the GNU v4.9.3 compiler. The CCS 7.3 debugger failed to display the values of the m_pMaster or m_pMasterPlat class variables, in the same way as when the program was run on a Cortex-A15.

2) Started the CCS 7.3 gdb_agent_console program using the board data file created by CCS:

C:\Users\mr_halfword\E2E_example_projects_CCS7\AM3352_GCC_class_variables\Debug>\ti\ccs730\ccsv7\ccs_base\common\uscif\gdb_agent_console.exe "c:\Users\mr_halfword\AppData\Local\Texas Instruments\CCS\ccs730\0\0\BrdDat\testBoard.dat"
CPU Name             Port
--------             ----
cortxa8             :55000
m3_wakeupss         :55001

Starting all cores
CPU Name             Status
--------             ------
cortxa8              Waiting for client
m3_wakeupss          Waiting for client
cortxa8              Client connected...Connecting to Target
cortxa8 - Processor type =CORTEX_A8 (Little endian)
cortxa8 - Target device is connected
Using ctools hardware breakpoint support.
Target connected...Starting server

Ran the arm-none-eabi-gdb program from the gcc-arm-none-eabi-4_9-2015q3 installed by CCS, and used commands to load the program compiled by GCC v4.9.3 using the CCS project, and stepped the test program:

C:\Users\mr_halfword\E2E_example_projects_CCS7\AM3352_GCC_class_variables\Debug>c:\ti\ccs730\ccsv7\tools\compiler\gcc-arm-none-eabi-4_9-2015q3\bin\arm-none-eabi-gdb.exe
GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <gnu.org/.../gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<www.gnu.org/.../>.
Find the GDB manual and other documentation resources online at:
<www.gnu.org/.../>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) target remote localhost:55000
Remote debugging using localhost:55000
0x8001208c in ?? ()
(gdb) file AM3352_GCC_class_variables.out
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading symbols from AM3352_GCC_class_variables.out...done.
(gdb) load
Loading section .rsthand, size 0x70 lma 0x80000000
Loading section .text, size 0x134dc lma 0x80000070
Loading section .ARM.extab, size 0x160 lma 0x8001354c
Loading section .ARM.exidx, size 0x208 lma 0x800136ac
Loading section .data, size 0x8d8 lma 0x800138b8
Loading section .jcr, size 0x4 lma 0x80014190
Start address 0x80000050, load size 82320
Transfer rate: 153 KB/sec, 924 bytes/write.
(gdb) b main
Breakpoint 1 at 0x80000158: file ../AM3352_GCC_class_variables.cpp, line 14.
(gdb) continue
Continuing.

Breakpoint 1, main () at ../AM3352_GCC_class_variables.cpp:14
14          if (m_pMaster == NULL)
(gdb) step
16              m_pMaster = new MasterClass();    // allocate it in the heap zone
(gdb) step
MasterClass::MasterClass (this=0x80014c28) at ../master_class.cpp:11
11      MasterClass::MasterClass()
(gdb) step
ChildClass::ChildClass (this=0x80014c30) at ../child_class.cpp:10
10      ChildClass::ChildClass()
(gdb) step
13      }
(gdb) step
MasterClass::MasterClass (this=0x80014c28) at ../master_class.cpp:14
14      }
(gdb) step
main () at ../AM3352_GCC_class_variables.cpp:19
19          m_pMaster->masterValue = 5;
(gdb) step
20          m_pMasterPlat.masterValue = 10;
(gdb) step
22              return 0;
(gdb) print *m_pMaster
$1 = {_vptr.MasterClass = 0x800120d8 <vtable for MasterClass+8>, masterValue = 5, m_child = {
    _vptr.ChildClass = 0x800120b0 <vtable for ChildClass+8>, value0 = 65535, value1 = 65534}}
(gdb) print m_pMasterPlat
$2 = {_vptr.MasterClass = 0x800120d8 <vtable for MasterClass+8>, masterValue = 10, m_child = {
    _vptr.ChildClass = 0x800120b0 <vtable for ChildClass+8>, value0 = 0, value1 = 0}}
(gdb)

The output of the print *m_pMaster and print m_pMasterPlat commands in the GDB console show that the GDB from the GNU v4.9.3 installation can correctly display the contents of the class variables which the CCS 7.3 debugger fails to. This points at problem in how the CCS debugger interprets the debug information from the GNU v4.9.3 compiler. 

The AM3352 test program is attached AM3352_GCC_class_variables.zip