feat(newlib): add option to disable eval of expression in assert() when NDEBUG set
Closes IDFGH-479 and IDFGH-8692
See merge request espressif/esp-idf!32887
According to the standard assert(X) should be replaced by a void expression when
NDEBUG is set. IDF's behavior was to not trigger an assertion, but we would still
evaluate X, e.g. if X was a function it would be ran.
This MR adds a kconfig option CONFIG_COMPILER_ASSERT_NDEBUG_EVALUATE which allows us
revert the behavior to be inline with the standard.
With IDF v6.0 the plan is to make CONFIG_COMPILER_ASSERT_NDEBUG_EVALUATE=n the default
behavior.
Closes https://github.com/espressif/esp-idf/issues/10136
Closes https://github.com/espressif/esp-idf/issues/2758
Probably GCC-13.x and on-wards uses "-fmerge-constants" to merge
the const section (string/floating-point) across compilation units.
This makes it difficult to properly analyze the size output of rodata
section across libraries, the merged section (big in size) is showed
across a single library.
The config option added here can help to disable this compiler behavior
and help to provide better size analysis. It can be used during
development phase only as it increases rodata section size.
The -Werror=all activates error for all warnings in -Wall, however, it
does not activate error for other default warnings, such as:
- int-conversion (pointer from integer w/o a cast)
- incompatible-pointer-types
- discarded-qualifiers
Which are IMO even more important that -Wall.
This commit fixes that by activating error for all warnings (i.e. from
-Wall and default ones) and removing those from -Wextra, as the culprit
commit seemed to address.
Fixes: 60f29236f6 "Build system: Raise warning level" (2016-11-16)
In order to avoid long analysis during esp-idf upgrade, provide a way to
restore the previous -Werror=all behavior that consider only warnings
from -Wall (and not default ones).
Also add a hint to use the Kconfig option on compilation error, but warn
that fixing the code is the preferred way.
Merges https://github.com/espressif/esp-idf/pull/11239
Suggested-By: Ivan Grokhotkov <ivan@espressif.com>
- As the PMA entry that made some memory regions cacheable was
assigned the highest priority, some intermediate inaccessible
memory regions bypassed protection.
- Added tests for the same
- Verified that even after changing the priority of the PMA entry,
a write operation at SOC_IRAM_LOW + 0x40 (a random RAM cached address)
still needs the same number (29) of CPU cycles.
The implicit promise of heap_alloc_caps() and friends is that the memory it
returns is fit for the purpose as requested in the caps field. Before
this commit, that did not happen; e.g. DMA-capable memory wass returned
from a correct region, but not aligned/sized to something the DMA subsystem
can handle.
This commit adds an API to the esp_mm component that is then used by the
heap component to adjust allocation alignment, caps and size dependent on
the hardware requirement of the requested allocation caps.
