rt: fix veneer limit position in linker script

[luojia65]

This pull request fixes a CMSE related bug. If we define #[cmse_nonsecure_call] segments it would generate functions in .gnu.sgstubs, but we would eventually found out that for unknown reason __veneer_base == __veneer_limit, where SAU configuration to this segment would be impossible.
The reason for this bug is unknown, but after this pull request it would link into correct limit value.

I wrote an example for this fix: https://github.com/IoTS-P/trustzone-m-rs/tree/sgstub-fixed . Before this pull request, this project builds but it would print like SG function stub region is at 0x10005fc0 .. 0x10005fc0, resulting in secure fault. After this pull request, it would print SG function stub region is at 0x10005fc0 .. 0x10005fe0 and runs successfully.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @thalesfragoso (or someone else) soon.

Please see the contribution instructions for more information.

[therealprof]

Looks good to me. Second opinion?

[jannic]

Related issue, which explains why this workaround is necessary:
https://bugs.launchpad.net/gcc-arm-embedded/+bug/1930219
(Some more context here: https://answers.launchpad.net/gcc-arm-embedded/+question/697333)

[adamgreig]

Ugh, how weird. I think this is fine then but we should leave a comment behind for the benefit of future readers, something like this?

[jannic]

BTW, I'm not even sure it's a linker bug. The linker puts the veneer directly into the output section .gnu.sgstubs, it's not imported by the input section *(.gnu.sgstubs*).

For verification, this linker script still works:

  .gnu.sgstubs : ALIGN(32)
  {
    __veneer_base = .;
  } > FLASH
  __veneer_limit = .;

Whereas this causes an error arm-none-eabi-ld: no address assigned to the veneers output section .gnu.sgstubs:

  .gnu.sgstubs_renamed : ALIGN(32)
  {
    __veneer_base = .;
    *(.gnu.sgstubs*);
  } > FLASH
  __veneer_limit = .;

As far as I can tell, there is no way to specify at which location within the section the veneer will be placed. What can be observed is that the linker places the veneer at the very end of the section. So if __veneer_limit = .; is placed within the output section description, the linker will place the veneer after that.

Conclusion: This pull request seems to be the correct solution. (And *(.gnu.sgstubs*) could be removed to avoid confusion, however I'm not sure if that would have undesired side effects.)

[adamgreig]

So if __veneer_limit = .; is placed within the output section description, the linker will place the veneer after that.

Ah, I guess that explains it! OK, perfect, I think this PR is fine then. Thanks for explaining.

The comment should perhaps reflect that instead, just because otherwise someone might try and move it back inside one day. We could also add a comment to *(.gnu.sgstubs*) to say it's not actually used by the linker but kept as a talisman against future misfortune.

[luojia65]

Hello! I accepted change from @adamgreig and I'm afraid that everyone have to review this pull request again before it's getting merged on GitHub :)

[adamgreig]

Thanks!

bors r+

[bors]

Build succeeded:

• ci-linux (1.59.0)
• ci-linux (stable)
• clippy
• hil-compile-rtt
• hil-qemu
• rt-ci-linux (1.59.0)
• rt-ci-linux (stable)
• rt-ci-other-os (macOS-latest)
• rt-ci-other-os (windows-latest)
• rustfmt