In embedded systems, stackoverflows can be catastrophic if the processor does not support virtual memory which is true of many(most?) microcontrollers that micropython is meant to support.

I understand that it is not feasible to rewrite micropython to not need recursion, especially if stackoverflows are so infrequent. However, it is possible to at least put in code to catch a stackoverflow.

Using cflow, I've generated the complete call tree of micropython and found there is recursion all over the place.

If I'm interpreting the cflow output correctly, there are 15 distinct "recursion loops" and total of 35 functions that exist in those recursive loops.

I think the macro MP_STACK_CHECK() needs to be added to (at least) one function in each recursive loop.
For example, it should be added to mp_obj_new_exception_msg_varg.

1 +-abort_() <__attribute__ () void () at abort_.i:1659>
    2   +-nlr_jump()
    3   \-mp_obj_new_exception_msg() <mp_obj_t () at objexcept.i:2328>
    4     \-mp_obj_new_exception_msg_varg() <mp_obj_t () at objexcept.i:2332> (R)
    5       +-m_malloc_maybe() <void * () at malloc.i:2077>
    6       | \-malloc()
    7       +-mp_obj_new_tuple() <mp_obj_t () at objtuple.i:1889> (R)
    8       | \-m_malloc() <void * () at malloc.i:2063> (R)
    9       |   +-malloc()
   10       |   \-m_malloc_fail() <void () at runtime.i:3697> (R)
   11       |     +-nlr_jump()
   12       |     \-mp_obj_new_exception_msg_varg() <mp_obj_t () at objexcept.i:2332> (recursive: see 4) [see 4]
   13       +-strchr()