fix(esp_ulp): Add support for multiple ULP program embedding without name collision (IDFGH-14151) #14951
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Currently, the ULP's auto variable name embedding script has multiple issues:
This PR fixes it:
nm
cross compilation tool toreadelf
tool for extracting symbols. This allows keeping the symbol's scope (global or local), the symbol type (object or function or ...) and the symbol size (for arrays).ulp_lp_core_lp_ana_peri_intr_handler
ulp_
prefix, but now, you can specify it)ULPmain::
and it'll mangle the name and work withoutextern "C"
): perfect to move the shorter variables in their own namespace and avoid collisions without dumb long namesuint32_t myVariable[32]
is correctly exported so can be used like a native variable in HP core, no more hacky((uint32_t*)myVariable)[0]
like specified in the documentation.From a user perspective, nothing changes (the useless symbol will be removed, but they couldn't be used anyway previously).
However, she can now replace the line:
to this:
And build collision-free and working multiple ULP binary.
Related
Fix #14945 and other issues too related to misusage of ULP symbols in HP core.
Testing
I've tested on my system with ESP32C6. I haven't tested with other CPU types. However, the tools used in this PR are common cross compilation tools, it shouldn't depend on the CPU architecture.
Checklist
Before submitting a Pull Request, please ensure the following: