Fix unwinding past main on OSX#511
Conversation
|
@kangaroo Nice finding! I wonder if this logic is platform specific enough that we should consider moving it into PAL under platform specific ifdefs and change PAL_VirtualUnwind to return a status code instead of a boolean so we don't have to derive the current state in VirtualUnwindToFirstManagedCallFrame based on the ControlPc value? What do you think? |
|
@kangaroo I would also prefer doing that in PAL. We can either change the PAL_VirtualUnwind to return status as Sergiy has suggested or, detecting that the PC has not changed over the unw_step call and zero the PC in the context in that case. It seems to me that the latter would be reasonable. |
65fb49c to
3acb996
Compare
|
Implemented it by coercing the $pc to 0x0 in the degenerate case as suggested by @janvorli. It turned out to be code cleaner than the flag, since it will return 0 from unw_step when it steps beyond the bottom, and into a managed frame, so we need to track $pc regardless. The code isn't 32-bit safe. I don't personally have any plan on doing bring up on OS X 32-bit, and would rather actually just remove all the 32-bit code, but thats a separate discussion. |
|
LGTM modulo the nits in the comments |
When reaching the bottom of the real stack, OSX does not change the $pc to 0x0, like llvm libunwind. It returns 0 from unw_step, and leaves the $pc unchanged, so we will track cur and prev pc and guard for this as well Fixes Localloc codegen test, and also verified a simple throw from main works as expected.
3acb996 to
c94716b
Compare
|
Fixed comment nits, squashed and pushed. |
|
Thanks! |
When reaching the bottom of the real stack, OSX does not change the $pc
to 0x0, like llvm libunwind. It returns 0 from unw_step, and leaves the
$pc unchanged, so we will track cur and prev pc and guard for this as well
Fixes Localloc codegen test, and also verified a simple throw from main
works as expected.
Fixes #510