[Possible Fix] PICO_DEOPTIMIZED_DEBUG has no effect after first configuration (causes breakpoint issues) #1618
Labels
No labels
bazel
bluetooth
board settings
boot_stage2
bug
build
c++
can't reproduce
clang
clib-interface
cmsis
code cleanliness
code size
compiler version issues
cyw43_driver
debug
discussion
documentation
duplicate
dynamic_clock
elf2uf2
enhancement
errata
filesystem
flash layout
floating point
FreeRTOS
hardware_adc
hardware_claim
hardware_clocks
hardware_dma
hardware_exception
hardware_flash
hardware_gpio
hardware_i2c
hardware_irq
hardware_pio
hardware_pwm
hardware_rcp
hardware_rtc
hardware_spi
hardware_sync
hardware_uart
hardware_vreg
hardware_watchdog
hardware_xosc
help wanted
host
IAR
installation
invalid
linker scripts
lto
lwip
mbedtls
missing API
needs reporter detail
networking
newlib
newlib-multicore
non-c
non-cmake
non-gcc
openocd
orphan PR
OS integration
pico_async_context
pico_base
pico_binary_info
pico_flash
picolibc
pico_lwip
pico_malloc
pico_multicore
pico_printf
pico_runtime
pico_stdio
pico_stdio_usb
pico_sync
pico_time
pico_util
pioasm
port
question
review
review2
rtos interop
runtime init
static library
svd
test
tinyusb
vscode
wifi integration
wontfix
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-raspberrypi/pico-sdk#1618
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Prefacing that I am new to using CMake and new to using debuggers, so take what I suggest with a grain of salt - but I believe I've identified a bug and a solution to it.
The problem:
In learning how to use picoprobe and VSCode's debugger, I configured a simple project with the Debug config using a minimal
CMakeLists.txtthat did not explicitly setPICO_DEOPTIMIZED_DEBUG. When I tried setting a breakpoint on the line:The breakpoint is greyed out in VSCode, delivering the error:
After a while of searching, it looked like this was a problem with compiler optimizations, so I tried enabling
PICO_DEOPTIMIZED_DEBUG, but reconfiguring didn't change any behaviour. To my surprise, however, deleting thebuilddirectory and configuring the project fresh produced the desired results; which got me digging...Likely cause:
My understanding is that setting
CMAKE_${LANG}_FLAGS_DEBUG_INITspecifically only sets the flags for the Debug config the first time it is configured. This would mean the debug flags get saved toCMakeCache.txtwhen you initially configure the project, and then all subsequent re-configurations that try to setCMAKE_${LANG}_FLAGS_DEBUG_INIThave no change to the already-cached value.What this means in this situation (I think) is that whatever
PICO_DEOPTIMIZED_DEBUGis set to / defaults to during your first configuration is what will dictate all subsequent debug flags untilCMakeCache.txtis deleted. I believe you can see this being the case by observing how the value ofCMAKE_C_FLAGS_DEBUGinCMakeCache.txtdoes not change after the initial configuration, regardless of changing the value ofPICO_DEOPTIMIZED_DEBUG.Proposed solution:
I think that this section in
cmake/preload/toolchains/set_flags.cmake:Needs to change to:
These changes remove
_INITon both commands and append the default debug flags (which is-gin this case, required for proper debugging). Appending the default flags keeps functional parity withCMAKE_${LANG}_FLAGS_DEBUG_INIT's intended behaviour.Additionally: What is the reasoning behind defaulting to an optimized debug, if optimizing breaks certain debug functionality? Perhaps this could be an opportunity to consider making deoptimized debug builds the default for debug builds with
PICO_DEOPTIMIZED_DEBUGdefaulting to1when it is declared, in combination with the above proposed change.I'd appreciate the eyes of someone who has been familiar with CMake for longer than a single week to validate that this is a real bug and a valid/safe solution. If this does sound reasonable, I'd be happy to submit a pull request with this simple change 🙂
Pass --fresh when running cmake and it ignores the cache
I'd prefer not to override a core feature of CMake when the solution proposed above addresses the issue directly.
Is there a reason I'm not aware of to preserve the use of
CMAKE_${LANG}_FLAGS_DEBUG_INIT, and ask users to overwrite the cache?No. If have a change to propose, raise a PR.
merged into develop