summaryrefslogtreecommitdiffstats
path: root/llvm/docs/LangRef.rst
diff options
context:
space:
mode:
authorCharles Davis <cdavis5x@gmail.com>2016-08-08 21:01:39 +0000
committerCharles Davis <cdavis5x@gmail.com>2016-08-08 21:01:39 +0000
commit0822aa118eafbe860acc393e076567697adda77a (patch)
treed5b7b3fb0545cf4634fe1e559165fdc35df63880 /llvm/docs/LangRef.rst
parent31f32fa62aab473aa58291af0a6984aa1a36f2ee (diff)
downloadbcm5719-llvm-0822aa118eafbe860acc393e076567697adda77a.tar.gz
bcm5719-llvm-0822aa118eafbe860acc393e076567697adda77a.zip
[X86] Support the "ms-hotpatch" attribute.
Summary: Based on two patches by Michael Mueller. This is a target attribute that causes a function marked with it to be emitted as "hotpatchable". This particular mechanism was originally devised by Microsoft for patching their binaries (which they are constantly updating to stay ahead of crackers, script kiddies, and other ne'er-do-wells on the Internet), but is now commonly abused by Windows programs to hook API functions. This mechanism is target-specific. For x86, a two-byte no-op instruction is emitted at the function's entry point; the entry point must be immediately preceded by 64 (32-bit) or 128 (64-bit) bytes of padding. This padding is where the patch code is written. The two byte no-op is then overwritten with a short jump into this code. The no-op is usually a `movl %edi, %edi` instruction; this is used as a magic value indicating that this is a hotpatchable function. Reviewers: majnemer, sanjoy, rnk Subscribers: dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D19908 llvm-svn: 278048
Diffstat (limited to 'llvm/docs/LangRef.rst')
-rw-r--r--llvm/docs/LangRef.rst20
1 files changed, 19 insertions, 1 deletions
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 7f69d693294..82f923ee1f7 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -1448,7 +1448,7 @@ example:
generated for this function needs to follow certain conventions that
make it possible for a runtime function to patch over it later.
The exact effect of this attribute depends on its string value,
- for which there currently is one legal possibility:
+ for which there currently are two legal possiblities:
* ``"prologue-short-redirect"`` - This style of patchable
function is intended to support patching a function prologue to
@@ -1464,6 +1464,24 @@ example:
``"prologue-short-redirect"`` is currently only supported on
x86-64.
+ * ``"ms-hotpatch"`` - This style of patchable function is similar to
+ ``"prologue-short-redirect"``, but it also imposes several additional
+ guarantees to support the style of hotpatching used on Windows. On
+ 32-bit x86, the first instruction will be a ``mov %edi, %edi``
+ instruction; this is frequently used as a magic value indicating a
+ hotpatchable function. On other architectures, however, the first
+ instruction can be anything allowed in a Windows-style prologue;
+ this is because all functions on the non-i386 architectures Windows
+ supports are assumed to be hotpatchable. Additionally, when not
+ targeting a Visual C++-style toolchain, patch space will be provided
+ prior to the function's entry point of an architecturally specific
+ size. These sizes are compatible with GCC: on 32-bit x86, the patch
+ space is 64 bytes long; on x86-64, it is 128 bytes long. The patch
+ space is not provided for MSVC toolchains because the
+ `/FUNCTIONPADMIN <https://msdn.microsoft.com/en-us/library/ms173524.aspx>`_
+ option, which provides this space, is expected to be used there.
+
+ ``"ms-hotpatch"`` is currently only supported on x86 and x86-64.
This attribute by itself does not imply restrictions on
inter-procedural optimizations. All of the semantic effects the
OpenPOWER on IntegriCloud