You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// Marks functions with the `marked_for_windows_hot_patching` attribute.
9
+
// Provides support for the Windows "Secure Hot-Patching" feature.
10
+
//
11
+
// Windows contains technology, called "Secure Hot-Patching" (SHP), for securely applying
12
+
// hot-patches to a running system. Hot-patches may be applied to the kernel, kernel-mode
13
+
// components, device drivers, user-mode system services, etc.
14
+
//
15
+
// SHP relies on integration between many tools, including compiler, linker, hot-patch
16
+
// generation tools, and the Windows kernel. This file implements that part of the workflow
17
+
// needed in compilers / code generators.
18
+
//
19
+
// SHP is not intended for productivity scenarios, such as Edit-and-Continue or interactive
20
+
// development. SHP is intended to minimize downtime during installation of Windows OS patches.
21
+
//
22
+
// In order to work with SHP, LLVM must do all of the following:
23
+
//
24
+
// * On some architectures (X86, AMD64), the function prolog must begin with hot-patchable
25
+
// instructions. This is handled by the MSVC `/hotpatch` option and the equivalent `-fms-hotpatch`
26
+
// function. This is necessary because we generally cannot anticipate which functions will need
27
+
// to be patched in the future. This option ensures that a function can be hot-patched in the
28
+
// future, but does not actually generate any hot-patch for it.
29
+
//
30
+
// * For a selected set of functions that are being hot-patched (which are identified using
31
+
// command-line options), LLVM must generate the `S_HOTPATCHFUNC` CodeView record (symbol).
32
+
// This record indicates that a function was compiled with hot-patching enabled.
33
+
//
34
+
// This implementation uses the `MarkedForWindowsHotPatching` attribute to annotate those
35
+
// functions that were marked for hot-patching by command-line parameters. The attribute
36
+
// may be specified by a language front-end by setting an attribute when a function is created
37
+
// in LLVM IR, or it may be set by passing LLVM arguments.
38
+
//
39
+
// * For those functions that are hot-patched, LLVM must rewrite references to global variables
40
+
// so that they are indirected through a `__ref_*` pointer variable. For each global variable,
41
+
// that is accessed by a hot-patched function, e.g. `FOO`, a `__ref_FOO` global pointer variable
42
+
// is created and all references to the original `FOO` are rewritten as dereferences of the
43
+
// `__ref_FOO` pointer.
44
+
//
45
+
// Some globals do not need `__ref_*` indirection. The pointer indirection behavior can be
46
+
// disabled for these globals by marking them with the `AllowDirectAccessInHotPatchFunction`.
47
+
//
48
+
// References
49
+
//
50
+
// * "Hotpatching on Windows": https://techcommunity.microsoft.com/blog/windowsosplatform/hotpatching-on-windows/2959541
51
+
// * "Hotpatch for Windows client now available": https://techcommunity.microsoft.com/blog/windows-itpro-blog/hotpatch-for-windows-client-now-available/4399808
52
+
// * "Get hotpatching for Windows Server": https://www.microsoft.com/en-us/windows-server/blog/2025/04/24/tired-of-all-the-restarts-get-hotpatching-for-windows-server/?msockid=19a6f8f09bd160ac0b18ed449afc614b
0 commit comments