mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-07-08 18:30:04 +00:00
1991e2a4df
Summary: This instruction encodes a loading operation that may fault, and a label to branch to if the load page-faults. The locations of potentially faulting loads and their "handler" destinations are recorded in a FaultMap section, meant to be consumed by LLVM's clients. Nothing generates FAULTING_LOAD_OP instructions yet, but they will be used in a future change. The documentation (FaultMaps.rst) needs improvement and I will update this diff with a more expanded version shortly. Depends on D10196 Reviewers: rnk, reames, AndyAyers, ab, atrick, pgavlin Reviewed By: atrick, pgavlin Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10197 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239740 91177308-0d34-0410-b5e6-96231b3b80d8
55 lines
1.7 KiB
ReStructuredText
55 lines
1.7 KiB
ReStructuredText
==============================
|
|
FaultMaps and implicit checks
|
|
==============================
|
|
|
|
.. contents::
|
|
:local:
|
|
:depth: 2
|
|
|
|
Motivation
|
|
==========
|
|
|
|
Code generated by managed language runtimes tend to have checks that
|
|
are required for safety but never fail in practice. In such cases, it
|
|
is profitable to make the non-failing case cheaper even if it makes
|
|
the failing case significantly more expensive. This asymmetry can be
|
|
exploited by folding such safety checks into operations that can be
|
|
made to fault reliably if the check would have failed, and recovering
|
|
from such a fault by using a signal handler.
|
|
|
|
For example, Java requires null checks on objects before they are read
|
|
from or written to. If the object is ``null`` then a
|
|
``NullPointerException`` has to be thrown, interrupting normal
|
|
execution. In practice, however, dereferencing a ``null`` pointer is
|
|
extremely rare in well-behaved Java programs, and typically the null
|
|
check can be folded into a nearby memory operation that operates on
|
|
the same memory location.
|
|
|
|
The Fault Map Section
|
|
=====================
|
|
|
|
Information about implicit checks generated by LLVM are put in a
|
|
special "fault map" section. On Darwin this section is named
|
|
``__llvm_faultmaps``.
|
|
|
|
The format of this section is
|
|
|
|
.. code-block:: none
|
|
|
|
Header {
|
|
uint8 : Fault Map Version (current version is 1)
|
|
uint8 : Reserved (expected to be 0)
|
|
uint16 : Reserved (expected to be 0)
|
|
}
|
|
uint32 : NumFunctions
|
|
FunctionInfo[NumFunctions] {
|
|
uint64 : FunctionAddress
|
|
uint32 : NumFaultingPCs
|
|
uint32 : Reserved (expected to be 0)
|
|
FunctionFaultInfo[NumFaultingPCs] {
|
|
uint32 : FaultType = FaultMaps::FaultingLoad (only legal value currently)
|
|
uint32 : FaultingPCOffset
|
|
uint32 : handlerPCOffset
|
|
}
|
|
}
|