Make spacer sections allocatable

[will-v-pi]

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't KEEP the .stack and .heap sections.

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:

• KEEP the sections - they show up in --print-memory-usage, and the binary runs fine
• Don't KEEP the 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

[will-v-pi]

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 develop branch of the SDK, then please raise a separate issue with details of your compiler.

[matsobdev]

False alarm. It was clean, but just those two files copied do 2.1.1. It works with develop.

[matsobdev]

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.

[will-v-pi]

But, 2.1.1 with copied files and work around was showing 2 KB of scratch Y usage, but now with develop it shows 0 KB. Do I miss some definition or something? But still there is something.

If you use this branch in this PR (not the develop branch), it should show 2KB of scratch Y usage - this hasn't been merged into develop yet, hence why develop still shows 0KB.

[matsobdev]

Shame on me :D Yes, it works with this branch and shows 2 KB.

[will-v-pi]

Putting back into draft due to compatibility issues with picotool encryption

[kilograham]

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

[will-v-pi]

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.

[will-v-pi]

Putting back into draft due to compatibility issues with picotool encryption

raspberrypi/picotool#243 fixes these issues