On some Windows systems, antivirus, endpoint-security or DLP/encryption
software intercepts short-lived toolchain processes and strips their
stdout when the build captures it through a pipe, while the same command
prints its output normally when run by hand. The tool exits successfully
but returns nothing, and each build step that reads toolchain output then
failed with a different, cryptic error far from the real cause:
- CMake configuration aborted with "Unknown arguments specified" in
components/xtensa/project_include.cmake, or "check_expected_tool_version
invoked with incorrect arguments" in components/esp_common.
- ldgen turned the empty objdump output into an opaque pyparsing
"Expected 'In archive'" traceback.
- idf_tools.py silently reported the compiler/debugger version as
"unknown", sending users into a fruitless reinstall loop.
Detect the empty result at each consumer and fail (or warn) with an
actionable message that names the likely cause and the remedy:
- tools/cmake/compiler_query.cmake: new __compiler_query() helper runs a
compiler query and fails with a clear error on empty or failed output.
It is a standalone module included by both the cmakev1 and cmakev2
utilities, since the esp_common and xtensa project_include.cmake that
call it are shared by both build systems. The xtensa if() arguments are
now quoted so an empty result no longer collapses into a parse error.
- tools/ldgen/ldgen.py: _run_objdump() rejects empty objdump output, and
non-empty-but-unparsable section info is caught and re-raised as a clear
LdGenFailure instead of a raw pyparsing traceback.
- tools/idf_tools.py: empty version output now warns with the cause and
returns UNKNOWN_VERSION instead of silently reporting "unknown".
Closes https://github.com/espressif/esp-idf/issues/18727
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Before:
The cache won't be disabled when XIP on psram. But during flash
erasing/programming, read data will be courrupt.
When XIP in psram is enabled, the image is not mapped to the cache so
usually there will be no flash access. The only way to read from flash
is via the driver or use mmap. The driver has protection during erasing,
while th mmap region not.
Now:
Mmap APIs provide a flag to make mmap->unmap region mutually exclusive
to flash erase/programming when XIP from psram. SPI Flash write APIs
will benefit from this. When the flag is used, no concurrent access to
mapped region will happen while writing; otherwise the cache will be
disable to avoid data corruption.
Most ESP-IDF APIs calls mmap with this flag. As for users calling
mmap-like APIs directly, they can choose whether to enable this by a
flag.
Closes https://github.com/espressif/esp-idf/issues/14897
ESP_FAULT_ASSERT(C) was silently deleted by the optimizer when C is a cached
flag/status already proven by a preceding `if (!C) return/goto`: the compiler
folds C to a constant and drops all three checks, removing the fault-injection
protection with no warning.
esp_http_client_set_redirection() now rejects any redirect target whose
scheme is not https:// when the origin is HTTPS. This catches http, ftp,
ws and any other scheme before client state is mutated. Same-host /
https-to-https redirects are unaffected. Apps that intentionally want
mixed-scheme redirects can set disable_auto_redirect=true and handle
HTTP_EVENT_REDIRECT.
platform.c (compiled into the 'builtin' archive) calls
esp_mbedtls_mem_calloc and esp_mbedtls_mem_free directly by name via
the MBEDTLS_PLATFORM_STD_CALLOC/FREE macros in esp_config.h.
Previously, esp_mem.c was compiled into the 'tfpsacrypto' archive, which
appears after 'builtin' in the link command, causing the linker to fail
with undefined reference errors when 'builtin' was processed first.
Moving esp_mem.c into 'builtin' to assure that the function used by
esp_mbedtls_mem_calloc and esp_mbedtls_mem_free are available when
pltform.c is linked.
Add a test app that verifies PLACE_IN_SECTION, _SECTION_ATTR_SYMBOL_DECL_GENERIC,
_SECTION_START and _SECTION_END macros work correctly on Linux.
The test places 5 uint32_t values into a custom .test_data_table section from
two separate translation units, then iterates the section at runtime to verify
the correct count and content of all entries.
Includes:
- Custom linker script (ld/test_section.ld)
- Build-test-rules entry (linux only)
- pytest host_test marker
Add PLACE_IN_SECTION, _SECTION_ATTR_IMPL_GENERIC, _SECTION_ATTR_SYMBOL_DECL_GENERIC,
_SECTION_START and _SECTION_END macros that emit real section attributes on every
platform (embedded ELF, Linux ELF, macOS Mach-O).
Unlike _SECTION_ATTR_IMPL which is a no-op on Linux, these macros work uniformly
across all targets, enabling link-time arrays for error-code tables, init-function
arrays, and similar patterns.
Also moves _COUNTER_STRINGIFY definition before its first use.
IDF_BUILD_V2 does not have BUILD_COMPONENTS build property. Therefore,
when IDF_BUILD_V2 is defined, use idf_component_optional_requires and
generator expressions instead. I believe that the one-liner should also
work with IDF_BUILD_V1, but the change is kept separate to clearly show
the difference between IDF_BUILD_V1 and IDF_BUILD_V2.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
