[SLOF] [PATCH slof] fdt: Avoid recursion when traversing tree

[Alexey Kardashevskiy]

On 17/07/2020 20:28, Segher Boessenkool wrote:
> On Fri, Jul 17, 2020 at 07:39:53PM +1000, Alexey Kardashevskiy wrote:
>> Well, this too but it is just some waiting :)
>>
>>> you seem to be talking about dysfunction of SLOF, which would be caused
>>> by stack exhaustion if I understand Segher's anwser correctly, right ?
>>
>>
>> Right. I am a bit surprised SLOF did not barf with "stack overflow" though.
> 
> I do not know the current state of this well, so apply salt as needed...
> 
> It is much too much overhead to check the stack pointer always
> (executing a single virtual machine insn is just a handful of real
> machine instructions!) 


This all true but yet there is "ERROR: stack overflow in engine()" and I
saw these in the past, and there others. But I never got to understand
it completely their limits, Thomas would probably know.



> A traditional approach is to only check the
> stack in the outer interpreter loop (where you have to find every name
> that is used in the dictionary anyway, or parse numbers, or anything
> else that costs thousands of cycles *anyway*!)
> 
> Many paflof configurations unmap the pages right above and below the
> stacks, to trap such things.  That does let slight underflows through,
> because the top element is not usually actually stored on the stack.
> 
> SLOF runs in real mode, so there are no guard pages, you can write to
> all RAM always.

Yes :(


> By default the interactive interpreter prints the stack depth at every
> prompt.  This is very helpful while writing and testing code.  And with
> the "test everything you write as soon as you write it" approach, most
> problems are avoided.  Exceptions are capacity problems (like here), or
> anything else that cannot be tested for easily (hardware problems for
> example).
> 
> So, perhaps this tree traversal code should call some "test the stack
> pointers and scream" word at strategic places?  At the start of handling
> any subtree for example.
> 
> (If some heavier routine is called for every node, you can put the test
> *there* instead, without making everything slow).

Making everything slow is perfectly fine for debugging SLOF. Thankfully
SLOF is not that complicated (real mode, 1 CPU, 1 device open at the
time) and normally a VM config is enough to reproduce the problem.



-- 
Alexey