Skip to content

fix(libsodium): disable GCC static analyzer for libsodium#715

Merged
mahavirj merged 1 commit into
masterfrom
fix/libsodium_disable_gcc_static_analyzer
Apr 1, 2026
Merged

fix(libsodium): disable GCC static analyzer for libsodium#715
mahavirj merged 1 commit into
masterfrom
fix/libsodium_disable_gcc_static_analyzer

Conversation

@fhrbata
Copy link
Copy Markdown
Collaborator

@fhrbata fhrbata commented Mar 30, 2026

Summary

  • Adds -fno-analyzer compile option to the libsodium component when CONFIG_COMPILER_STATIC_ANALYZER is enabled with GCC
  • GCC's -fanalyzer causes the compiler to hang indefinitely on libsodium's elliptic curve code (ed25519_ref10.c) due to combinatorial state explosion in the interprocedural analysis
  • This is the same approach already used by ESP-IDF for mbedtls, wpa_supplicant, freertos, and other components

Closes espressif/esp-idf#18373

Test plan

  • Verified that without the fix, building a minimal project with CONFIG_COMPILER_STATIC_ANALYZER=y and espressif/libsodium dependency hangs indefinitely (GCC's cc1 stuck at 100% CPU on ed25519_ref10.c)
  • Verified that with the fix, the same project compiles ed25519_ref10.c successfully and the build completes

@fhrbata fhrbata requested a review from mahavirj March 30, 2026 09:47
Comment thread libsodium/CMakeLists.txt
@mahavirj
Copy link
Copy Markdown
Member

@fhrbata please bump the component version

LGTM!

GCC's -fanalyzer flag, enabled by CONFIG_COMPILER_STATIC_ANALYZER=y,
causes the compiler to hang indefinitely when analyzing libsodium's
elliptic curve code (crypto_core/ed25519/ref10/ed25519_ref10.c). The
-fanalyzer pass performs deep interprocedural static analysis, tracking
symbolic state across all function calls within a translation unit.
The complex field element arithmetic in ed25519_ref10.c (multiply,
square, carry propagation) with many static helper functions visible
in the same translation unit causes combinatorial state explosion in
the analyzer, making GCC's cc1 process run at 100% CPU indefinitely.

In a parallel build, this blocks all dependent steps (linking, binary
generation) while independent steps finish normally, making the build
appear stuck at "Completed 'bootloader'" — the last independent ninja
target to complete.

This is the same approach already used by ESP-IDF for mbedtls,
wpa_supplicant, freertos, and other components with complex code that
triggers pathological behavior in GCC's static analyzer.

Closes espressif/esp-idf#18373

Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
@fhrbata fhrbata force-pushed the fix/libsodium_disable_gcc_static_analyzer branch from cecedaa to ce0dfeb Compare March 31, 2026 09:59
@fhrbata
Copy link
Copy Markdown
Collaborator Author

fhrbata commented Mar 31, 2026

@fhrbata please bump the component version

LGTM!

Version bumped, thank you!

@mahavirj mahavirj merged commit 0d74ee3 into master Apr 1, 2026
40 of 47 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

idf.py build hangs on Completed 'bootloader' step

2 participants