Fix linker scripts to define _end correctly #57727
Merged
Conversation
This file contains 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
keith-packard
requested review from
dcpleung,
nashif,
andyross,
julius-barendt,
jhedberg,
kgugala,
pgielda,
carlocaione,
stephanosio,
MaureenHelm,
galak,
ioannisg,
abrodkin,
ruuddw,
evgeniy-paltsev,
tejlmand,
aasthagr and
dleach02
as code owners
stephanosio
reviewed
May 10, 2023
keith-packard
force-pushed
the
define-_end
branch
3 times, most recently
from
4dfefd1
to
3bd49e0
Compare
stephanosio
reviewed
May 10, 2023
There was a problem hiding this comment.
Looks good to me.
Can you please fix the compliance check failure regarding the first commit message?
1: UC3 Commit title does not follow [subsystem]: [subject] (and should not start with literal subsys:): "Fix linker scripts to define _end after all static RAM data"
tejlmand
previously approved these changes
May 10, 2023
galak
previously requested changes
May 10, 2023
What "new" symbol? |
Aside from the fact that |
60 tasks
|
@stephanosio -- could this be considered for 3.4? It's a fatal error when linking with picolibc using the default common malloc configuration settings on smaller targets for most architectures. |
jhedberg
previously approved these changes
Jun 2, 2023
andyross
previously approved these changes
Jun 2, 2023
|
@galak PTAL |
nashif
dismissed
galak’s stale review
please revisit and address questions/comments after your review.
|
@keith-packard can you rebase please? |
…M data The Zephyr linker scripts have inconsistent ordering of various chunks of data which lands in RAM at runtime. This leads to the value of _end not being consistently defined as the maximum address of static variables used in the application. Create a helper linker fragment, zephyr/linker/ram-end.ld, which can be included after the last possible definition of RAM data, that consistently sets _image_ram_end, _end and z_mapped_end. Signed-off-by: Keith Packard <[email protected]>
The generated scripts don't include a definition for any symbol indicating the end of statically allocated memory (such as "_end"). Add a shared cmake fragment, ram-end.cmake, which contains the necessary instructions to define _end and z_mapped_end consistently to align with the other sample linker scripts. Signed-off-by: Keith Packard <[email protected]>
keith-packard
dismissed stale reviews from andyross, jhedberg, stephanosio, dcpleung, cfriedt, and tejlmand
via
38e23a1
keith-packard
force-pushed
the
define-_end
branch
from
a48f204
to
38e23a1
Compare
tejlmand
approved these changes
Jun 28, 2023
fabiobaltieri
approved these changes
Jun 28, 2023
duda-patryk
added a commit
to Semihalf/zephyr
that referenced
this pull request
Jun 30, 2023
Currently, this section has LOAD flag which means that it's part of image layout. Attempt to generate binary file with --gap-fill results in creating a very big file, because LMA of the section is RAM address (e.g. 0x20000000 for STM32F4) instead of FLASH (e.g. 0x8000000 for STM32F4). This problem doesn't appear when linking using GNU LD, because it removes the section in garbage collect process. However, LLVM LLD doesn't garbage collect sections that define used symbols, so the section is present in final ELF image. There is no need to load this section (it has 0 size), so we can safely add NOLOAD attribute to the section. Fixes: zephyrproject-rtos#57727 Signed-off-by: Patryk Duda <[email protected]>
fabiobaltieri
pushed a commit
that referenced
this pull request
Jul 5, 2023
Currently, this section has LOAD flag which means that it's part of image layout. Attempt to generate binary file with --gap-fill results in creating a very big file, because LMA of the section is RAM address (e.g. 0x20000000 for STM32F4) instead of FLASH (e.g. 0x8000000 for STM32F4). This problem doesn't appear when linking using GNU LD, because it removes the section in garbage collect process. However, LLVM LLD doesn't garbage collect sections that define used symbols, so the section is present in final ELF image. There is no need to load this section (it has 0 size), so we can safely add NOLOAD attribute to the section. Fixes: #57727 Signed-off-by: Patryk Duda <[email protected]>
cfriedt
pushed a commit
to cfriedt/zephyr
that referenced
this pull request
Jul 5, 2023
Currently, this section has LOAD flag which means that it's part of image layout. Attempt to generate binary file with --gap-fill results in creating a very big file, because LMA of the section is RAM address (e.g. 0x20000000 for STM32F4) instead of FLASH (e.g. 0x8000000 for STM32F4). This problem doesn't appear when linking using GNU LD, because it removes the section in garbage collect process. However, LLVM LLD doesn't garbage collect sections that define used symbols, so the section is present in final ELF image. There is no need to load this section (it has 0 size), so we can safely add NOLOAD attribute to the section. Fixes: zephyrproject-rtos#57727 Signed-off-by: Patryk Duda <[email protected]>
cfriedt
pushed a commit
to cfriedt/zephyr
that referenced
this pull request
Jul 6, 2023
Currently, this section has LOAD flag which means that it's part of image layout. Attempt to generate binary file with --gap-fill results in creating a very big file, because LMA of the section is RAM address (e.g. 0x20000000 for STM32F4) instead of FLASH (e.g. 0x8000000 for STM32F4). This problem doesn't appear when linking using GNU LD, because it removes the section in garbage collect process. However, LLVM LLD doesn't garbage collect sections that define used symbols, so the section is present in final ELF image. There is no need to load this section (it has 0 size), so we can safely add NOLOAD attribute to the section. Fixes: zephyrproject-rtos#57727 Signed-off-by: Patryk Duda <[email protected]>
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.
_end must point past the last address of statically allocated RAM in the application. Adjust the linker scripts to use a new fragment which does this. Adjust the cmake linker script generator to do the same.