MCUXpresso debug view showing incorrect variable names

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

MCUXpresso debug view showing incorrect variable names

ソリューションへジャンプ
1,717件の閲覧回数
frank_m
Senior Contributor III

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.

frank_meyer_0-1612447663222.png

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 ?

0 件の賞賛
返信
1 解決策
1,639件の閲覧回数
converse
Senior Contributor V

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.

元の投稿で解決策を見る

0 件の賞賛
返信
9 返答(返信)
1,714件の閲覧回数
converse
Senior Contributor V

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?

0 件の賞賛
返信
1,709件の閲覧回数
frank_m
Senior Contributor III

Thanks for the quick resonse.

> Does it think you are in the LCD_DrawChar function?

I would think so:

frank_meyer_0-1612452735353.png

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 ...

frank_meyer_1-1612453047770.png

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.

0 件の賞賛
返信
1,702件の閲覧回数
converse
Senior Contributor V

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).

0 件の賞賛
返信
1,693件の閲覧回数
frank_m
Senior Contributor III

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 ...

0 件の賞賛
返信
1,680件の閲覧回数
converse
Senior Contributor V

-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 

0 件の賞賛
返信
1,679件の閲覧回数
frank_m
Senior Contributor III

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.

0 件の賞賛
返信
1,644件の閲覧回数
frank_m
Senior Contributor III

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.

0 件の賞賛
返信
1,640件の閲覧回数
converse
Senior Contributor V

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.

0 件の賞賛
返信
1,638件の閲覧回数
frank_m
Senior Contributor III

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 ...

0 件の賞賛
返信