Fix possible overflow of .data region in FLASH

[Guilucand]

Hi,

i found a bug on the size checking of the FLASH region, that in some cases allows it to be larger than it's defined size.
This happens because the .data section is placed on a FLASH address (at the end of __erodata) but it's not checked against the FLASH region size.
Changing the section as shown solves the issue.

[rust-highfive]

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

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[jonas-schievink]

Could you maybe provide an example where this happens? I'd expect the linker to catch an issue like that, even without these changes.

[Guilucand]

Hi,
i've made an example repository that triggers the unwanted behavior:
https://github.com/Guilucand/cortex-m-rt-flash-overflow-example

The problem only happens when the flash size is smaller than the ram size,
so i set the flash size to 64K and the ram size to 256K, and allocate an array of 100K bytes.
If you build the example with:
cargo build --release
the linker throws an error because the array is in .rodata and it's checked against the FLASH bounds.
If instead you build the example with:
cargo build --release --features trigger-overflow
the linker produces a binary with a .data section size of 100K, overflowing the FLASH region.

[jonas-schievink]

bors r+

[bors]

Build succeeded:

• ci-linux (1.39.0)
• ci-linux (stable)
• Rustfmt

[adamgreig]

It looks like this PR basically half-reverts d5f2a94 since we used to use AT > FLASH and then changed to AT(__erodata) instead, to fix #188 and rust-lang/rust#65391.

Maybe @therealprof will recall why that was necessary, and perhaps we should check we haven't re-introduced those bugs.

[therealprof]

I guess the thinking was that the .erodata would be sufficient to constrain the placement of the sections which is why I've removed the AT > FLASH. It is quite possible that this assumption doesn't hold under some conditions. I have no objection to readding this but maybe it would be possible to add regression test case for this.

[jonas-schievink]

Since that PR has fixed linkage errors, but linking still works, I guess it didn't reintroduce those problems