Hi Mike,
Yes, I just noticed this option in the Kconfig:
choice
prompt "Optimization Level"
default DEBUG_NOOPT if DEBUG_SYMBOLS
default DEBUG_FULLOPT if !DEBUG_SYMBOLS
Probably this is from the days when GCC for ARM and other chips didn't
work well with debug enable and optimization enabled.
I think this is not a requirement anymore. But it is hard to say,
because NuttX support *a lot* of different architectures beyond ARM
and Xtensa.
BR,
Alan
On 9/18/23, Mike Moretti <nu...@mordent.com.invalid> wrote:
> This is the kind of thing that really should be documented somewhere.
> In bold, "DO NOT TURN OFF OPTIMIZATION because...". Either that or
> disallow it being changed, or make FULLOPT the default for every platform?
>
> I only stumbled upon this because I missed copying one single config
> line (the FULLOPT=y one) from the sample esp32s3 config files to our
> custom board file and didn't think it actually mattered when I was
> diffing the generated configs with the sample generated configs for
> verification (because, you know, it's just "optimization", and normally
> in any other typical development environment I would actually want noopt
> for debugging). And without it, the default was NOOPT and crashes.
>
> -m
>
>
> On 9/18/2023 11:55 AM, Tiago Medicci Serrano wrote:
>> Hi Mike,
>>
>> NuttX + Espressif's SoCs are intended to be built with optimization
>> enabled. Otherwise, few practical applications would be possible and
>> you'd
>> need to reconsider stack sizes, for instance. So, please don't disable
>> optimization while building practical applications.
>>
>> Usually, it isn't needed to disable optimization to debug the code, but
>> If
>> you really need to turn it off to debug a specific function, consider
>> using
>> the attribute `__attribute__((optimize(0)))`.
>>
>> Best regards,
>>
>> Em seg., 18 de set. de 2023 às 12:05, Alan C. Assis <acas...@gmail.com>
>> escreveu:
>>
>>> Hi Mike,
>>>
>>> I remember facing similar issue with ESP32 in the past.
>>>
>>> Because I started using NuttX with ARM chip and in the past the GCC
>>> toolchain has some issue with you are trying to compile debug symbols
>>> (-g) and optimization enabled (-O2) I always disabled optimization
>>> while enabling debugging. (Fortunately those day are gone, currently
>>> gcc for ARM Cortex chips work fine with -g and -O2 at same time).
>>>
>>> So when I started working with Xtensa I replicated this same behavior,
>>> disabling the optimization and enabling the debug. So it started to
>>> fail.
>>>
>>> So some friends with more experience in Xtensa instructed me to just
>>> use the -g and -O2 at same time. And I never investigate further about
>>> it.
>>>
>>> Probably this same issue will happen on ESP-IDF (just guessing, I
>>> didn't check it). I think it could be a good place to start your
>>> investigation.
>>>
>>> BR,
>>>
>>> Alan
>>>
>>> On 9/18/23, Mike Moretti <nu...@mordent.com.invalid> wrote:
>>>> Hi,
>>>>
>>>> I'm using NuttX 12.2.1 with ESP32S3 and have been trying for days to
>>>> figure out why it crashes on boot with our custom board/app. It turns
>>>> out that turning off CONFIG_DEBUG_FULLOPT and turning on
>>>> CONFIG_DEBUG_NOOPT is what's causing my issue (via menuconfig). The
>>>> default from all the other esp32s3 configurations has FULLOPT on and
>>>> NOOPT off. So, to verify it wasn't just in our custom board/app, I
>>>> tried this on the default esp32s3-devkit:wifi configuration, and IT DID
>>>> THE SAME THING, it crashes! This is the second time I've had an issue
>>>> with random configuration settings causing the nuttx code to crash
>>>> arbitrarily. (The first was enabling CONFIG_DEBUG_ASSERTIONS for esp32
>>>> doing the same thing, which I previously posted about).
>>>>
>>>> What the heck is going on? Is the esp32/s3 port really this unstable?
>>>>
>>>> -m
>>>>
>>
>
>
