• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 54 subscribers
  • Views 4197 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCSv6.1.1: Any way to view static variables in the expressions window?

stevenh
Guru 20035 points

Hello,

As mentioned at 

C2000 v6.4.9: volatile variable not showing up in memory map - Code Composer Studio forum - Code Composer...

e2e.ti.com
Hello, A variable defined as volatile static Uint16 u16SineWaveIndex = 0; is not showing up in the memory map file. u16SineWaveIndex is used in an inlined function
adding--mapfile_contents=sym_defs to my projects linker options allows static variables to show up in the map file.  However, it doesn't allow static variables to be viewed in the expressions window.

Is a there any way to view static variables in the expression window without modifying the code (which also includes creating code as shown below) ?

#ifdef DEBUG
    #define STATIC
#else
    #define STATIC static
#endif

STATIC unsigned int a;

Static variables have an address, so why aren't they allowed to be shown in the expression window?

Stephen

  • 0
    TI__Intellectual 2625 points

    By default, if you type 'a' in the expression view, CCS will search 'a' using current debug context ( the stack frame you have selected in the debug view).
    So, if you are currently debugging codes in the file where 'a' is defined, you should be able to access it.
    However, if you want to access the variable when you are not debugging the same source file, you should prefix the variable name with the file name, i.e. 'foo.c'::a

    Regards,
    Raymond

  • 0 in reply to Raymond Pang
    Guru 20035 points

    Hello Raymond,

    That doesn't work for the attached project.  Could you please see what's causing the issue.

    Thanks,

    Stephen

    7510.TestOptimization123.zip

  • 0 in reply to Raymond Pang
    Guru 20035 points

    Hello Raymond,

    The assembly code for project I posted is shown below.  As you can see u16SineWaveIndex is located at address 0xC009 and abc is located at 0xC00A.

    While debugging the source code, the Expression window shows the following:

    Assembly Code:

            main():
009078:   761F0300    MOVW         DP, #0x300
10          u16SineWaveIndex++;
00907a:   0A09        INC          @0x9
25      }
00907b:   9A00        MOVB         AL, #0x0
00907c:   761F0300    MOVW         DP, #0x300
6           abc++;
00907e:   0A0A        INC          @0xa
00907f:   0006        LRETR        
40      {
        _nop():
009080:   0006        LRETR

  • 0 in reply to stevenh
    TI__Intellectual 2625 points
    I have looked into your project.
    The debug info for u16SineWaveIndex does not indicate which source file the variable was declared.
    That is why we do not associate it with main.c.
    In my opinion, this is a compiler issue.
    I will report to the compiler team.

    Raymond
  • 0 in reply to Raymond Pang
    Guru 20035 points

    Thanks.

    Will you reply with the answer in this thread or will this thread be moved to the compiler forum?

  • 0 in reply to stevenh
    TI__Intellectual 2625 points
    A bug has been filed. The compiler team will investigate.
    The CQ # is SDSCM00052706 CCS cannot find static variables in some C2000 CG tools compiled object file.
  • 0 in reply to stevenh
    TI__Intellectual 855 points

    Hi Stephen,

    I took a look at your project and the issue appears to be that link time optimization (aka whole program optimization) is being used in the debug build.  (--opt_level=4).  What's happening is that during this optimization, the files are being mixed together in such a way that the debug information is no longer clearly delineated between files.  (Which is representative of what happens during link time optimization to the code itself.)

    As a general rule, the higher the optimization level, the higher the degradation of debug information, and this is an example of that.  If you lower the optimization, you should be able to view the static variables.

    Thanks,

    Zachary Morgan

  • 0 in reply to Zachary Morgan
    Guru 20035 points

    Hello Zachary,

    This seems to be a deficiency with the compiler tool set.  Am I correct?

    Before optimization, I would think the compiler tool set could figure out which variables are associated with which file and save that information for later use.

    Stephen

  • 0 in reply to Zachary Morgan
    Guru 20035 points

    Hello Zachary,

    Since this is a compiler issue, could you please move this thread over to the compiler forum.

    Thanks,

    Stephen

  • 0 in reply to stevenh
    TI__Intellectual 855 points

    > I would think the compiler tool set could figure out which variables are associated with which file and save that information for later use.

    The problem is a little more involved. The way link time optimization works is by taking the input translation units and concatenating them into a single translation unit so that the toolchain has greater context to optimize with.

    With DWARF debug information, CCS's answer to "which static foo is this?" is answered by the containing DWARF compilation unit (which is approximately equivalent to the idea of a translation unit in source code.) A compilation unit can only claim to be from a single file so it claims to be from no individual file, if that makes sense.

    Further, due to multiple possible static foo's, they become foo$1, foo$2, etc inside of that compilation/translation unit. That is, due to being put into a single translation unit, the original static variables have been replaced with uniquely named ones.

    That being said, it may be possible to break up the monolithic link time optimized DWARF compilation unit into multiple compilation units to be more representative of the original source -- I will track this issue as such.

  • 0 in reply to Zachary Morgan
    Guru 20035 points

    How will you track it?

  • 0 in reply to stevenh
    TI__Intellectual 855 points
    Under the same ticket: SDSCM00052706. I have revised it to be an enhancement instead of a defect since this is a quality-of-implementation issue and not a correctness issue.
  • 0 in reply to Zachary Morgan
    Guru 20035 points

    You might want to remove the reject reason, so there's no confusion.

    Thanks,
    Stephen