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.

MSP430FR5964: Code Composer Studio not showing local variables

Part Number: MSP430FR5964

A couple of weeks back I was working through a code composer issue where multiple break points were being generated for a single (C) source line This was subsequently resolved by migrating the build optimization level from -O0 (None) to -Og (Optimize for debugging).

I've just noticed that with some builds (not all, and haven't figured out the pattern yet), local variables are now not being displayed in the Variables window, and cannot even be added in the Expression window. This is all with the build optimization at -Og. Moving the optimization back to -O0, makes these visible again.

So I'm guessing that -Og is somehow suppressing symbol information for local variables. Why it would do this for a optimization model that is supposedly for supporting debug, I haven't a clue. It doesn't feel logical, so I'm suspecting something else is at play.

Any ideas?

CCS is V10.4, toolchain is GCC


  • For the local variables can be visible just the code go into the function that used this variable. 

  • This IS inside the function that defines and uses the variables.

    But it's not every function and/or variable. Some functions show none of their local variables, some show them all, and have found one that only shows some of them?? Switching to -O0 and rebuilding shows all the variables (I think) 

  • Some functions show none of their local variables

    What's the case do you mean? I suppose you have set a break point into this function to watch the local variables, right?

  • Optimization can *eliminate* variables, so there is nothing to show.

  • Actually first saw this on the entry to main(), but that's just an implicit breakpoint. And yes, all the occurrences are viewed either from breakpoints, or subsequent steps from a breakpoint (for instance following execution into a routine)

    This reminds me of a weird problem that goes back to the old Eclipse IDE days. It's all vague memory now, but I think this used to miss local variables in the top level (main itself), and you used to work around this with a spurious call immediately after main entry. But I don't think this is the same, as definitely see this at multiple places in the call stack.

    I'm back at the optimise levels. -O0 is supposedly no optimisation, and haven't seen the problem there. Which brings up the (mysterious?) -Og optimisation, which I have been using to get round a previous issue where -O0 was resulting in multiple break points being generated for the same source line. The only information I have found on -Og is from the GCC manual, and it states;

    Optimize debugging experience. ‘-Og’ should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience. It is a better choice than ‘-O0’ for producing debuggable code because some compiler passes that collect debug information are disabled at ‘-O0’.

    Based on this, I wouldn't expect -Og to be suppressing symbol information, but I'm afraid that's a bit of a black box

  • Hi Andrew

    The other way to verify if the variable be optimized, you search it in the map file. And if the variable be optimized, you will not allow to put a breakpoint at the line in your code that used this variable.