Newer GNU bin-utils version 2.39 has started emitting a warning
about an executable stack region for Linux target build:
/usr/bin/ld: warning: x509_crt_bundle.S.o: missing .note.GNU-stack section implies executable stack
Fix the issue by adding appropriate "noexecute" attribute for stack
section.
For the Linux target, we currently attempt to fallback to older C/CXX
lagnuage standards in the __build_set_lang_version() function. The
language standard support is checked using CMake's language-specific
functions, such as check_c_compiler_flag(). These functions require the
language to be enabled[1] in CMake beforehand, which is done by calling
project() or by enabling the languages later with enable_language(). At
present, we use enable_language() to enable C and CXX languages in
CMake, allowing us to set the standard early, before invoking project().
However, newer CMake versions (>3.29) issue a warning[2] if
enable_language() is called before project(), as noted in CMP0165[3].
It should generally be acceptable to call __build_set_lang_version()
after __project(), but doing so would alter the behavior of the
COMPILE_OPTIONS also for non-Linux targets. Currently, users can
add to COMPILE_OPTIONS even before calling project() in the project's
CMakeLists.txt and the options will be in the desired order. In other
words, appending to COMPILE_OPTIONS can occur either before or after
calling project() in the project's CMakeLists.txt, with the outcome
remaining consistent. This means the user's settings will appear later
and take priority. However, if __build_set_lang_version() is called
after __project(), the user's COMPILE_OPTIONS settings would be
overridden if set before calling project(). Our documentation[4] explicitly
states that COMPILE_OPTIONS and similar properties should be modified
using idf_build_set_property() after calling project() to prevent
default values from overwriting them.
Even with this guidance, some existing components that modify
COMPILE_OPTIONS before invoking project() might be impacted by this
change. Therefore, separate the language standard settings for non-Linux
and Linux targets. For non-Linux targets, these settings are applied in
__build_set_default_build_specifications(), maintaining the current
behavior. For the Linux target, the language standard is set with
__linux_build_set_lang_version() after calling __project(), ensuring the
languages are already enabled in CMake and no warning is issued. Since the Linux
target is still in preview, this approach should be acceptable,
especially with the existing documentation[4].
Closes https://github.com/espressif/esp-idf/issues/15488
[1] https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#languages
[2] https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9396
[3] https://cmake.org/cmake/help/latest/policy/CMP0165.html#policy:CMP0165
[4] https://docs.espressif.com/projects/esp-idf/en/v5.4/esp32/api-guides/
build-system.html#overriding-default-build-specifications
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
This feature is useful for 3rd-party software to run GDB with predefined
options that described in project_description.json file
allow to pass custom options to "idf.py gdb":
--gdb-commands: command line arguments for gdb. (without changes)
-ex: pass command to gdb.
-x: pass gdbinit file to gdb. Alias for old --gdbinit command
By default, esp-idf-size.ng displays all sections individually. This can
be confusing, especially if CONFIG_SOC_MEM_NON_CONTIGUOUS_SRAM is
enabled, resulting in sections like .dram0.data and .dram1.data being
abbreviated as two .data sections in the size report. To avoid confusion
for idf.py and cmake users, pass the --unify option to the underlying
esp_idf_size.ng by default.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Previously the error message was
CMake Error at /home/user/esp-idf/tools/cmake/build.cmake:296 (__component_get_property):
__component_get_property Function invoked with incorrect arguments for
function named: __component_get_property
Call Stack (most recent call first):
/home/user/esp-idf/tools/cmake/build.cmake:341 (__build_resolve_and_add_req)
/home/user/esp-idf/tools/cmake/build.cmake:638 (__build_expand_requirements)
/home/user/esp-idf/tools/cmake/project.cmake:710 (idf_build_process)
CMakeLists.txt:6 (project)
Now it will be:
CMake Error at /home/user/esp-idf/tools/cmake/build.cmake:298 (message):
Failed to resolve component 'whatever' required by component 'main'.
Call Stack (most recent call first):
/home/user/esp-idf/tools/cmake/build.cmake:345 (__build_resolve_and_add_req)
/home/user/esp-idf/tools/cmake/build.cmake:642 (__build_expand_requirements)
/home/user/esp-idf/tools/cmake/project.cmake:710 (idf_build_process)
CMakeLists.txt:6 (project)
Also improved the hint to show the component name in quotes.
Closes https://github.com/espressif/esp-idf/pull/14036
[Frantisek Hrbata: fixed spelling not related to this change so spellcheck succeeds]
[Frantisek Hrbata: modified the error message to be recognized by the existing hint]
[Frantisek Hrbata: added also check in idf_component_set_property and simple tests]
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
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>
There is currently a bug in the __build_resolve_and_add_req function in
tools/cmake/build.cmake where the check for registered component
requirements is incorrectly applied to the component itself rather than
its dependencies. This issue likely originated from a typo, using
component_target instead of _component_target. To prevent further
confusion, _component_target has been renamed to _req_target.
Fixing this revealed multiple incorrect dependencies for the Linux
target, which have now been resolved by explicitly specifying the
dependencies for the Linux target.
Closes https://github.com/espressif/esp-idf/issues/13447
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
This adds a possibility to specify --diff option to idf.py size,
size-components and size-files commands. This can be map file directly,
project directory or build directory.
Usage example:
idf.py size-components --diff ../hello_world2/build/hello_world.map
idf.py size-components --diff ../hello_world2/build
idf.py size-components --diff ../hello_world2
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
For Linux builds if the embedded data length exceeded 16-bit value then
the build used to fail with following error:
build/x509_crt_bundle.S: Assembler messages:
build/x509_crt_bundle.S:4201: Warning: value 0x1056e truncated to 0x56e
GNU ASM for X86 systems treats .word attribute as of size 2 bytes, this commit
uses .long attribute to take the size to 4 bytes.
This commit enables the standad VERSION argument for the project() macro
in ESP-IDF. The VERSION argument is compilant with the requirements of
cmake 3.16. This commit also adds new test cases for verifying the
validity of the version argument.
Merges https://github.com/espressif/esp-idf/pull/12461
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
