Closed devjoa closed 9 months ago
thank you for your proposal.
We have an example with custom linker script here. Could you please open an issue explaining a bit more in details what's wrong in your use case ? An (non working) example is welcome.
I'm sorry, the error I got from GCC was that I redefined the RAM segment in the MEMORY section. However, I can't recreate the problems I had with the linker script that made me create this commit. Neither with the custom-linker-script example nor with my "real" code. Therefore, I believe we can ignore and close this pull request.
I tried to make an application where I needed to change the
MEMORY
block. However, the default script that is provided by the SDK hindered me from doing this, asstm32_add_linker_script
is using the-T
option.If the SDK-provided script used
-Wl,--default-script=${SCRIPT}
instead, this wouldn't be a problem.This pull request fixes that problem. However, I couldn't nicely fix the problem without duplicating the
stm32_add_linker_script
.Previously, when using
stm32_add_linker_script
to define a custom linker script, the SDK provided a default linker script, that used the-T/--script
flag, which led to conflicts when you wanted a completely new user-provided linker script.The
--default-script
flag changes this behavior and makes it possible to derive from the SDK-provided linker script, but also enables the possibility to create a completely new linker script.This commit adds a new internal command
stm32_add_default_linker_script
that is used internally for the--default-script
flag, and normal users shouldn't be affected by this. Thus this should not be a breaking change if this function is used as normally intended.