aarch32-rt: Stack usage is transparent to linker

[umohr-irs]

The stacks are defined merely as pointers. This makes them not visible to the linker as memory area avoiding link time checks.
I would suggest putting them into their own NOLOAD section, maybe even in a separate memory region. This would bring the following benefits:

• Memory usage by stacks is checked by the linker. Currently, if one defined a stack size larger than the DATA memory region, the linker is happy to generate very invalid values for the stack pointers. The same applies if the stacks collide with valid data within DATA.
• the size utility shows the actual memory usage by the binary. Currently, the stacks are not included there.
• Memory usage is optimized as there is no "empty" region between .uninit and the stacks. With the output of size being correct, memory usage can be controlled more closely.

By introducing a separate memory region, it still would be possible to put the stacks at a defined location in memory for those who prefer it that way.

While this all can be changed by user defined linker scripts and code, I would prefer the example code to reflect this concept to not mislead the unsuspecting.

[jonathanpallant]

That's a good point. I'd be happy to take a PR that does this, as long as users still have the ability to control which segments the stacks end up in (e.g. to put them in CCRAM or some other TCM). I think I'm OK if all the stacks have to go into the same segment, but I'd be interested in hear arguments either way.

[umohr-irs]

I think having stacks go into separate segments sounds like something quite specific which will probably require a custom linker script anyway, but that's just my 2 cents.

I'll try to prepare a PR for this.

[robamu]

I like this idea. Not sure about whether the main stack should always require a size/dimension, but that would allow defining a completely static .stack and a separate .heap segment and allow a clean separation of them, which might be useful on systems with a lot of RAM where heap usage becomes feasable. I recently exerimented with embedded-alloc, and I like the idea of having a heap with RAM sizes exceeded 8MBs+, greatly simplifying library development for beefier systems..

NOTE: I think it is tricky for check that the main stack just exceeded its own static size if it has one. but maybe having that as a static segment would still allow some smart stack watermark mechanism in the software.