Build flags for debug (platformio)

[git2212]

Hello,

I was wondering what the proper build flags would be for ensuring that the variables are not optimized out for a pico-debug session?

I have the following in my platformio.ini that should be relevant:

..
board = waveshare_rp2040_zero
framework = arduino
upload_protocol = pico-debug  
debug_tool = pico-debug         
build_type = debug
...
build_flags = 
    -v                          ; turn on to see what the build command is
    -O0                         ; turn off optimizations
...

unfortunately many variables are still 'optimized out' while debugging as if the compiler ignored -O0 entirely. In fact it doesn't seem to matter what level of optimization is specified the results are always the same.

So not sure where this is unraveling, I don't think it's platformio as the build command seems to have all the right flags...

Suggestions?

[dwijtsma]

If you make your variables volatile, they will not be optimised out.

[git2212]

If you make your variables volatile, they will not be optimised out.

Yes that is true for most cases...some compilers ignore scoping suggested by {...} the volatile keyword doesn't always work either... as I found out

... I am not entirely certain that the intended purpose for volatile variables is to enable variables for debugging... I could be wrong

there has to be a way to control this somehow with a compiler flag (or two or three) lol since it is a compiler behavior/optimization issue.

[dwijtsma]

Volatile is used mostly i.c.w. interrupt functions. For the compiler thinks these functions are never called. As a result the compiler can assume a variable value is never changed or is never used. With volatile you force the compiler to give it a dedicated location in memory. If a compiler optimised away a volatile variable, the compiler is broken. Op vr 26 mei 2023 18:39 schreef git2212 ***@***.***>:

…

If you make your variables volatile, they will not be optimised out. Yes that is true for most cases...some compilers ignore scoping suggested by {...} the volatile keyword doesn't always work either... as I found out ... I am not entirely certain that the intended purpose for volatile variables is to enable variables for debugging... I could be wrong there has to be a way to control this somehow with a compiler flag (or two or three) lol since it is a compiler behavior/optimization issue. — Reply to this email directly, view it on GitHub <#1478 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUEBZKPHNXVRJUZMN365DDXIDMEJANCNFSM6AAAAAAYQMNHFE> . You are receiving this because you commented.Message ID: ***@***.*** .com>

[git2212]

Volatile is used mostly i.c.w. interrupt functions...

In a narrow scope true, the original purpose of volatile (from the days of real multi-core, multi-tasking OSes) evolved from the need to "fix" values which may be accessed from a different execution context. In Arduino land often all one has to worry about is an occasionally intruding interrupt handler (definitely in a different execution context) in an otherwise perfect sunny day. But even the simplest multi threading setup, the slightest possibility of concurrent access introduces "complications" which need to be solved and volatile is at the base of all solution one could argue, typically...

... but my question was not about how and when to use volatile, granted it is a sort of a fix but a dirty one at that. Why would I want to have to go through and flip variables (which have no reason to be volatile) to volatile just to debug... as I said, it would be reasonable to expect that this can be turned off at the compiler level.

I am guessing that the problem is that as people expect more and more from their compilers, those who write them implement more and more clever ways to optimize which often requires re-sequencing of operations, reallocation of memory regions, use of registers rather than the heap, etc. At the end of the day, it may not be possible to turn this off completely at the compiler level, if so, I'd argue the compiler is also broken because when you give it -O0, it is supposed to skip being clever. Now the build flag may vary depending on the tool chain but the fundamental idea is the same...

... still looking for that compile level flag lol

[git2212]

If a compiler optimised away a volatile variable, the compiler is broken.

is this supposed to hold for a struct data type as well?... one would think so , see below and note the struct evt is gone by the time we hit a breakpoint on line 69.

[maxgerhardt]

I was wondering what the proper build flags would be for ensuring that the variables are not optimized out for a pico-debug session?

You'd wanna use debug_build_flags for that and include -g3 -ggdb3 on top of the optimization level (-O0). You shouldn't build_flags for that.

debug_build_flags = -O0 -ggdb3 -g3

[git2212]

You'd wanna use debug_build_flags for that and include -g3 -ggdb3 on top of the optimization level (-O0)...

debug_build_flags = -O0 -ggdb3 -g3

This was the answer, thanks! The variables are not being optimized out.