Method for finding cold end of stack needs justification

[rptb1]

The manual advises the use of a stack marker to find the cold end of the stack: https://github.com/Ravenbrook/mps/blob/179341b6cc2d9ab623ea53d10914d66c3668d47d/manual/source/guide/lang.rst#L984-L995

Is this advice reliable with current compiler optimisations on our target platforms?

We should check and record our justification for it. We should also test for it, for example, by asserting about it in our tests, so that we are warned if it ever becomes false.

Incidentally, on this topic, design.mps.stack-scan.req.stack.cold.not says: https://github.com/Ravenbrook/mps/blob/179341b6cc2d9ab623ea53d10914d66c3668d47d/design/stack-scan.txt?plain=1#L48-L50

[rptb1]

We now have proof that the statement from the manual is false. A cold-end marker obtained this way does not necessarily include roots in the same stack frame. So the statement that the program's active local variables are placed after the marker is false. To get a reliable placement warmer than the marker you need to be in a child stack frame.

JPH proved this while editing the arena extension/contraction test.

[rptb1]

Even with https://github.com/Ravenbrook/mps/commit/b4d548562a7226978982c51df51bad473b314585 in place, extcon.c fails with gcc 11.3.0 under Ubuntu 22, apparently because gcc inlines test_main into main and reorders the locals. https://github.com/Ravenbrook/mps/commit/24e4c8614d8d4f956c6332335b6e6bf0e56305b3 contains a temporary workaround.

[rptb1]

https://github.com/Ravenbrook/mps/commit/627ded3fc9eb253d2eba8075762be8daced3608e contains a further workaround that was necessary on clang 14.

[thejayps]

addrobj.c has also been written in #223 subsequent to the creation of this issue in a way which avoids the issue (i.e. registering a static region of memory to hold ambiguous pointers rather than register the stack and store them there.) It's not known whether the issue would exist in addrobj.c had it been written in a way which used stack roots.