现代C++不支持安全的自修改代码，因操作系统W^X/DEP机制强制代码页不可写；需手动调用mprotect/VirtualProtect改权限并清指令缓存，且易因对齐、ABI、缓存同步等问题导致未定义行为。
为什么现代C++几乎不支持安全的自修改代码
直接说结论：在标准C++中，self-modifying code 不是可移植、可维护或可调试的合理选择；主流编译器（GCC/Clang/MSVC）默认生成只读代码段，尝试写入 .text 段会触发 segmentation fault 或 ACCESS_VIOLATION。这不是C++语言限制，而是操作系统级内存保护（W^X / DEP）强制要求——代码页不可写，数据页不可执行。
真实场景里，有人想用SMC做：热补丁、JIT函数内联、反调试混淆、极低延迟算法热替换。但绝大多数情况下，这些需求有更稳妥的替代方案。
如果真要绕过W^X执行写入代码逻辑，得手动改页权限
必须脱离C++抽象层，调用OS API临时将代码所在内存页设为可写+可执行。这和C++本身无关，本质是系统编程。
- Linux/macOS 用
mprotect()：先getpagesize()对齐地址，再mprotect(addr, len, PROT_READ | PROT_WRITE | PROT_EXEC) - Windows 用
VirtualProtect()：传入PAGE_EXECUTE_READWRITE，注意返回旧保护标志并恢复（否则影响ASLR/CFG） - 分配内存必须用
mmap(MAP_ANONYMOUS | MAP_PRIVATE)或VirtualAlloc(..., MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE)，不能用malloc()或栈内存——它们没执行权限 - 写完指令后，必须调用
__builtin___clear_cache()（GCC/Clang）或FlushInstructionCache()（Windows），否则CPU可能执行旧缓存的指令
示例片段（Linux）：
立即学习“C++免费学习笔记（深入）”；
uint8_t* buf = (uint8_t*)mmap(nullptr, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); mprotect(buf, 4096, PROT_READ | PROT_WRITE | PROT_EXEC); // 写入x86-64机器码，比如 ret 指令：0xc3 buf[0] = 0xc3; __builtin___clear_cache(buf, buf + 1); auto func = reinterpret_cast<void(*)()>(buf); func(); // OK
常见翻车点：指令编码、对齐、缓存与ABI
即使页权限搞定，SMC仍极易崩溃或行为异常，原因不在C++，而在底层细节被忽略：
- 手写机器码必须严格匹配目标架构和模式（x86-64 vs ARM64、小端序、RIP-relative寻址是否启用）
- 函数入口需满足ABI要求：比如x86-64 System V要求栈16字节对齐，未对齐可能导致后续
call失败 - 修改正在执行的函数？必须确保CPU已退出该函数，且无其他线程同时调用——否则竞态直接UB
- 现代CPU的分支预测器、微指令缓存（uop cache）可能未及时同步，
__builtin___clear_cache()仅保证指令TLB和L1i失效，某些ARM平台还需额外屏障 - 开启
-O2后，编译器可能把函数内联、拆分、插入栈保护，导致你定位的地址根本不是原始函数起始位置
更现实的替代方案：别硬刚SMC
真正关键的算法性能瓶颈，极少来自“无法动态改一行指令”，而常源于数据结构、缓存局部性或分支预测失败。与其折腾SMC，不如考虑：
- 用
std::function或函数指针数组 + 运行时查表切换策略（如不同输入规模选不同实现） - 借助编译器特性：GCC的
__attribute__((hot))/__attribute__((noinline))控制内联，Clang的#pragma clang loop(unroll(full)) - 需要极致定制？用LLVM JIT（
llvm::orc::KaleidoscopeJIT）生成函数，它内部已妥善处理页权限、重定位、符号解析 - 加密/混淆场景？用控制流扁平化或虚拟机解释器，比SMC更可控、更易调试
SMC不是黑魔法，它是把内存管理、指令集、CPU微架构和编译器行为全暴露在你面前的操作。一个没清的cache、一次错位的mprotect、一条未对齐的jmp，都足以让程序在某个特定CPU型号上静默失败。
