diff options
author | Simon Hausmann <simon.hausmann@digia.com> | 2013-05-12 12:07:15 +0200 |
---|---|---|
committer | Lars Knoll <lars.knoll@digia.com> | 2013-05-15 23:30:42 +0200 |
commit | 69c6209e1c337af1cc55f48c78937083dd2eba7e (patch) | |
tree | b42d7d902b7a255d7c5cdd83213d38f3434e3f0e /src/3rdparty/masm | |
parent | 727bdfa0d56cfdc3f327e4cd268b5e2ea10c5931 (diff) |
Fix exception handling not working reliably on x86/x86-64 Linux (Part 1)
The registration of the unwind tables is done through the interposition
of the _Unwind_Find_FDE symbol from libgcc. Unfortunately that interposition
breaks when libgcc happens to come first in the linker scope. As it turns
out, the order is not for us to control, therefore the interposition may not
always work and our JIT generated functions may not get their unwind information
found at exception throwing time. That results in the program aborting with
an uncaught exception.
The proposed solution of replacing the interposition approach is two-fold:
(1) Go back to calling __register_frame explicitly, but only for functions that
exception _may_ pass through. In addition the performance of scalability of the
objects registered with __register_frame is a known issue upstream, as the LLVM
JIT also triggers the issue. It is being tracked at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56460
(2) Instead of registering one FDE per function, we can theoretically register
one FDE for _all_ JIT generate functions, because they all use the same stack
layout that has exactly the same unwinding requirements from any function call
site. Since we can't guarantee the presence of all JIT generated code within
the same contiguous memory area, we can at least do it per executable memory
allocation chunk (page size). One chunk can contain many functions.
This patch implements part (1) by delaying the registration of the FDE to right
before the exception gets thrown and then walks up the context chain. The test
cases that were previously slowed down before commit
b83696f9896401dd5e99eed35e36628710e44eeb are not affected because the many
temporary "eval" functions are never subject to exceptions.
Change-Id: I7cb8262e3e1f27d6de71a1e42be8a538cba6513f
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Diffstat (limited to 'src/3rdparty/masm')
0 files changed, 0 insertions, 0 deletions