Stack overflow handling issue on ARM (32 bit)

[janvorli]

There is a problem with handling stack overflow on ARM when the stack overflow occurs in a leaf native function (in the libcoreclr.so or in any other native library like libc, etc). Such functions don't have any unwind information and are marked as ARM_EXIDX_CANT_UNWIND in the EHABI unwind info and the libunwind's unw_step fails to unwind them due to that. Currently, the HandleHardwareException tries to unwind to the first managed frame using the libunwind to get a starting frame to log the stack trace. But that fails and no stack trace is dumped.
Actually, there are couple more issues here:

• PAL_VirtualUnwind executed on a frame where a hardware exception occurred increments the PC in the context by 1 to compensate for the fact that libunwind decrements the PC before searching for unwind info for frames unless in knows it is a frame of a hardware exception. It cannot detect that a frame is a frame of hardware exception unless it has unwound through the signal handler, which doesn't occur in our case. However, the compensation we do doesn't seem to fully work on ARM in some cases and can lead to crashes during follow-up unwinds. I have found there is a libunwind_init_local2 function that takes an extra argument that can be used to tell libunwind the frame is a frame of hardware exception, so we should use it instead of the compensation.
• This compensation we do also blocks correct check for the unw_step not moving the PC that happens when no unwind info is found, so we actually think that PAL_VirtualUnwind successfully unwound the frame to PC+1.