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:

mps/manual/source/guide/lang.rst

Lines 984 to 995 in 179341b

	void *marker = ▮
	mps_root_t stack_root;
	res = mps_root_create_thread(&stack_root, arena, thread, marker);
	if (res != MPS_RES_OK) error("Couldn't create stack root");
	In order to scan the control stack, the MPS needs to know where the
	:term:`cold end` of the stack is, and that's the role of the
	:c:data:`marker` variable: the compiler places it on the stack, so its
	address is a position within the stack. As long as you don't exit from
	this function while the MPS is running, your program's active local
	variables will always be placed on the stack after :c:data:`marker`,
	and so will be scanned for references by the MPS.

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:

mps/design/stack-scan.txt

Lines 48 to 50 in 179341b

	_`.req.stack.cold.not`: There is no requirement to locate the cold end
	of the stack. (The mutator supplies this as an argument to
	``mps_root_create_thread()``.)

[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 b4d5485 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. 24e4c86 contains a temporary workaround.

[rptb1]

627ded3 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.