Variables "optimized out" in the local variables tab

[systemdlete]

I can only guess what it means when I am stepping through the debugger in Codelite (v16.0.0 on Devuan Chimaera) and one or more of the variables in the local variables tab indicate they have been "optimzied out." I have experience working with software, and I understand optimization. I am just not totally clear what codelite means by it. (Terminology in computing tends to be over-recycled, leading to a lot of confusion.)

At any rate, it is making it difficult to step through my program to see where the error is. I am sure it is not codelite-related because the same error occurs even when running the program outside of any debugger. Is there a way to disable this optimization? Or is this the result of corruption (maybe caused by my own code) such that codelite (or gdb backend) cannot determine the values of these variables?

[DavidGH]

Hi,

I know what you mean; I've seen it a lot, for years.

As you say, it's not a CodeLite thing. I'm no expert, but a quick search found this explanation.

Regards,

David

[Jarod42]

Debugging in "Release configuration" has some drawbacks, such as variable optimized out, (re)moved break-points (code optimized/inlined/...), unclear call stack (inlining/...).

Using "Debug configuration" (-O0) has not those drawbacks.

Unrelated to Codelite.
Pretty sure it is not related to corruption but just compilation settings (optimization) not "ideal" for debugger.

[systemdlete]

@Jarod, not sure what you mean by Debugging in "Release configuration" (remember, I am new with codelite). Do you mean codelite's own release configuration, or maybe gcc's? If this is an option for codelite, I'll try hunting it down and changing it. Thank you for your reply.

At any rate, I did look at gcc compiler options and found that I can use the options "-g3 -Og" to try to get a better compilation suitable for a debugger. There may be more options, such as the "--with" options, that may be helpful also. But I am still unable to debug my program.

I also have my own debug code, which I can include or exclude at random. If I disable it completely, I still have the bug(s), so I know they are not due to my own debug code (which has happened in the past with other work I've done. Sometimes the cure can be as deadly as the disease it seems).

I should have also mentioned in my OP that I am compiling for static binary. I need this for portability reasons.

Another thing I should have mentioned also is that I am using the gcc v10.2.1 suite; there seems to have been a number of updates and upgrades since then. I don't know if I want to chase down that rabbit hole particularly.

[systemdlete]

OK, I poked around and could not find that option (if that's what it is). There are of course the various configurations you can create with the wrench tool (workspace settings?), and I have created a couple of these already. I think that might be what you are referring to.

But I was able to solve my problem. I ended up using the options "-g3 -O0" (that's a zero after the capital "oh"). That does away with virtually all optimizations, and that allowed me to see exactly where I had shot my own foot off in my code. (It was a strcmp against a null value, of course!)

So I guess this is "solved," kinda. I mean, if we can trust that optimizations won't ever present a bug that would otherwise not occur. But I suppose we must place our faith in our tools to some degree at least.

[Jarod42]

Do you mean codelite's own release configuration, or maybe gcc's?

I meant your project configuration. how are built Codelite or gcc is irrelevant here.

We generally use different configurations depending on usages:

• Debug: with optimization turn-off, with symbol not stripped, with defines for extra log/check (...), to have all informations for debugging.
• Profile: which has some specific flag to collect metrics.
• Code coverage: to know which line/branches has been "visited" when running the code.
• tress tests: flag to favorise crash (for debugging).
• Release: to provide to final user, so "full" optimization.
• target/option dependent: 32bits/64bits, with libraryA or with libraryB, with support of featureA or not...
• ...

Some flags are compatible with several configurations, some are specific to some ones.
Some flag do some compromises.
Up to you how to handle the possible combination.

As you seems to see, -g, -ggdb, -g3, -O0 or -Og are valid flags for debugging.