diff options
author | Charles Davis <cdavis5x@gmail.com> | 2016-08-08 21:01:39 +0000 |
---|---|---|
committer | Charles Davis <cdavis5x@gmail.com> | 2016-08-08 21:01:39 +0000 |
commit | 0822aa118eafbe860acc393e076567697adda77a (patch) | |
tree | d5b7b3fb0545cf4634fe1e559165fdc35df63880 /llvm/docs/LangRef.rst | |
parent | 31f32fa62aab473aa58291af0a6984aa1a36f2ee (diff) | |
download | bcm5719-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.rst | 20 |
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 |