Fix OSX personality routines encoding
authorJan Vorlicek <janvorli@microsoft.com>
Tue, 12 May 2015 15:31:09 +0000 (17:31 +0200)
committerJan Vorlicek <janvorli@microsoft.com>
Tue, 12 May 2015 16:50:16 +0000 (18:50 +0200)
commite04202d6f58648230ab467da6d1e14aa8db4d2a7
tree53b48358af5f6962323a261ff51d4c87b7004253
parentf9d6fc2a569b6639ff20c1c678c16de8e61d9530
Fix OSX personality routines encoding

This change fixes a crash that occured in case a managed callback
called from a native code throws an exception. The correct behavior
is to exit the process and dump the managed call stack. It works ok
on Linux, but on OSX, it crashes with segmentation violation trying
to execute code at address 4.
The problem is caused by the fact that either the assembler or
the linker ignores personality routines specified using the encoding
0 (absolute pointer) and stores value 4 instead of the routine address
no matter what routine is specified.
Fortunatelly, there is another encoding that can be used and that works.
It is an indirect PC relative encoding (code 0x9b).
However, there is another problem. The linker issues a warning when there
are more than 3 personality routines in the whole libcoreclr.dylib:
ld: warning: too many personality routines for compact unwind to encode
As for now, I have removed the ExceptionHijackPersonalityRoutine from
the ExceptionHijack asm helper to fix this problem.
We will need to figure out what to do about it once we enable the thread
hijacking on Unix. This personality routine's purpose is to make stack
walker walk stack of a highjacked function as if the highhack routine was
called from it. It seems we can use a different technique for that -
to create a helper frame that would have IP pointing to a function that
is never called, but has an unwind info that ensures that we walk
through the hijack correctly. The same technique is used for hardware
exception handling on OSX.
src/debug/ee/amd64/dbghelpers.S
src/pal/inc/unixasmmacros.inc