Make spacer sections allocatable #2515
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ALLOCATE_SPACERS config option to disable the behaviour
…ustom linker scripts
|
There are some problems: Worked around by commenting out ifs here: pico-sdk/src/rp2_common/pico_crt0/crt0.S Lines 79 to 83 in b8f5b4f and here (making the first option the only one): pico-sdk/src/rp2_common/pico_crt0/crt0.S Lines 206 to 216 in b8f5b4f |
|
None of those errors are related to this PR, they're all related to #2233 - to get those errors, did you definitely do a clean compilation with the branch from this PR. Or did you just copy the changed files from this PR into an existing 2.1.1 SDK, which will not work as crt0.S relies on changes to other files in #2233 to compile correctly. If you can reproduce those errors in a clean compilation (deleted build directory) using the |
|
False alarm. It was clean, but just those two files copied do 2.1.1. It works with develop. |
|
But, 2.1.1 with copied files and work around was showing 2 KB of scratch Y usage, but now with develop (including updated libraries and picotool) it shows 0 KB. Do I miss some definition or something? But still there is something. GCC 14.2.1. |
If you use this branch in this PR (not the |
|
Shame on me :D Yes, it works with this branch and shows 2 KB. |
|
Putting back into draft due to compatibility issues with picotool encryption |
|
note also, i'm curious if this causes the contents to be stored in the binary? This would be bad in general, but particularly egregious for the heap |
This causes extra LOAD segments to appear in the ELF, but they have a filesize of 0 so have no data actually stored in the file. |
raspberrypi/picotool#243 fixes these issues |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
As raised in #2513, the current way of specifying stack and heap space means that on GCC the space is not included in
--print-memory-usage, because they are not marked as allocatable in order to maintain compatibility with linker scripts prior to 1.5.1 which don'tKEEPthe.stackand.heapsections.This changes that default to mark them as allocatable, and adds a new CMake function to parse the linker script and check for compatibility, and enables a workaround if not compatible.
This means if you:
KEEPthe sections - they show up in--print-memory-usage, and the binary runs fineKEEPthe sections - they don't show up in--print-memory-usage, and CMake raises warnings at the configure stage explaining the incompatibility, but the binary still runs fine