Skip to content
This repository was archived by the owner on Jan 23, 2023. It is now read-only.

Fix unwinding past main on OSX#511

Merged
jkotas merged 1 commit into
dotnet:masterfrom
kangaroo:unwind-fix-two
Mar 20, 2015
Merged

Fix unwinding past main on OSX#511
jkotas merged 1 commit into
dotnet:masterfrom
kangaroo:unwind-fix-two

Conversation

@kangaroo
Copy link
Copy Markdown

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

@sergiy-k
Copy link
Copy Markdown

@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?

@janvorli
Copy link
Copy Markdown
Member

@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.
You've also said in #510 that we cannot differentiate between walking out of stack and walking to a managed frame. Are you sure about that? Since when we step out of the last native frame, the unwinder still has all the information to do so, it just cannot move further. And if it didn't work, I don't see how the current exception handling could work, since the first step is to move to the first managed frame by walking out of the native ones.

@kangaroo
Copy link
Copy Markdown
Author

@janvorli Sorry I meant we cannot detect it on the result code of unw_step alone.

@sergiy-k I think a status flag could work possibly be a little cleaner -- I'll try it out tonight.

@kangaroo
Copy link
Copy Markdown
Author

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.

@janvorli
Copy link
Copy Markdown
Member

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.
@kangaroo
Copy link
Copy Markdown
Author

Fixed comment nits, squashed and pushed.

jkotas added a commit that referenced this pull request Mar 20, 2015
Fix unwinding past main on OSX
@jkotas jkotas merged commit 76446cc into dotnet:master Mar 20, 2015
@jkotas
Copy link
Copy Markdown
Member

jkotas commented Mar 20, 2015

Thanks!

@kangaroo kangaroo deleted the unwind-fix-two branch March 20, 2015 17:05
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fix unwinding out of Main on OSX

5 participants