MCUXpresso debug view showing incorrect variable names

[frank_m]

I searched the forum before, but didn't find any matching the issues I have.

I am using MCUXpresso IDE v11.1.1 [Build 3241] [2020-03-02], with an OM13098 board (LPCXpresso54628) as hardware.

I am not seeing correct local variables, especially variable names, and I con't see what I am doing wrong.

As seen, the names in the variable view do not match the names declared in the current function at all. Nor does their number. Some are updated while stepping through, and the value and change seems plausible. Which would IMHO indicate the debugger is in the right stack frame.

Has anybody experienced such an issue ?

[converse]

What does the stack frame show (the Debug view in the IDE). Does it think you are in the LCD_DrawChar function? If yes, do you have any functions that are inlined? Do you have any other threads? Are you running non-stop debugging?

[frank_m]

Thanks for the quick resonse.

> Does it think you are in the LCD_DrawChar function?

I would think so:

No there are no inlined functions.

Doing a search for the displayed variable names, they all show up in another function of the same module, which is never called. Which I find a bit confusing ...

There are no threads either, and I just do breakpoints and single-step.

My experiences with non-stop debugging or realtime update (or however it is called) had ... not been so good. At least on other toolchains.

[converse]

What level of Debug (-g?) and optimisation (-O?) do you have on your build?

Also, do you have ---gc-sections in the linker? This can cause problems with the debug symbol table (removes unused functions from the image, but is not always successful at removing its associated debug symbols!) - try removing --gc-sections from your debug build (although it will increase the size of your image).

[frank_m]

Except for a few sources (including the one containing shown function), this is the unmodified lcdc_tft example from the SDK.

Default settings I had been using are O0 (no optimisation) and "--gc-sections" defined. Which, if I remember correctly, places functions in individual section, for easier removal by the linker.

Going to experiment with this settings, albeit I still don't understand why the debugger loads wrong symbols ...

[converse]

-ffunction-sections is a compiler option to place functions into Individual sections

--gc-sections is a linker option to remove unused sections

When the linker removes unused sections it does not always correctly remove the corresponding debug information associated with that removal. This can lead to all sorts of weird issues (it can remove the wrong debug information, or misalign it, for example), including the one you are seeing 

[frank_m]

This would make sense.

In the meantime I had simply removed some of the "offending" functions, and the problem was gone. The forum has swallowed my respective post, though ...

Over the weekend, I try another IDE installation I have, a recent version running under Linux.

[frank_m]

FYI, I tried the latest toolchain version (11.3.0, if I remember correctly), and it made no difference.

The problem was the same, and the workaround as well.

[converse · Accepted solution]

I'm not surprised - this is a persistent problem with the GNU toolchain. I've been using GNU for over 10 years and it still occasionally bites me. Generally it works but it does (for no known reason) get it wrong on occasions. Sometimes, just re-ordering the functions in a module is sufficient to 'fix' the issue.

[frank_m]

I was a bit surprised, actually. Dabbling about a decade in the embedded business (and occasionally with gcc toolchains), I never came across this issue. 

For private purposes, I often use the gcc-based Crossworks - which never had this problem, despite intensive usage. My companies payed dearly for uVision or IAR-WB licenses, which have their own compilers.

However, the free toolchains to push a vendor's hardware seems to have been putting bugfixing on the back burner... I know toolchains quite a bit worse than MCUXpresso.

Hoping it can at least be helpful for others, I'm putting an and to the discussion ...