[flang-commits] [clang] [flang] [llvm] [flang] Add runtime trampoline pool for W^X compliance (PR #183108)
Sairudra More via flang-commits
flang-commits at lists.llvm.org
Sun Aug 9 21:46:06 PDT 2026
================
@@ -0,0 +1,454 @@
+//===-- lib/runtime/trampoline.cpp -------------------------------*- C++-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// W^X-compliant trampoline pool implementation.
+//
+// This file implements a runtime trampoline pool that maintains separate
+// memory regions for executable code (RX) and writable data (RW).
+//
+// On Linux the code region transitions RW → RX (never simultaneously W+X).
+// On macOS Apple Silicon the code region uses MAP_JIT with per-thread W^X
+// toggling via pthread_jit_write_protect_np, so the mapping permissions
+// include both W and X but hardware enforces that only one is active at
+// a time on any given thread.
+//
+// Architecture:
+// - Code region (RX): Contains pre-assembled trampoline stubs that load
+// callee address and static chain from a paired TDATA entry, then jump
+// to the callee with the static chain in the appropriate register.
+// - Data region (RW): Contains TrampolineData entries with {callee_address,
+// static_chain_address} pairs, one per trampoline slot.
+// - Free list: Tracks available trampoline slots for O(1) alloc/free.
+//
+// Thread safety: Uses Fortran::runtime::Lock (pthreads on POSIX,
+// CRITICAL_SECTION on Windows) — not std::mutex — to avoid C++ runtime
+// library dependence. A single global lock serializes pool operations.
+// This is a deliberate V1 design choice to keep the initial W^X
+// architectural change minimal. Per-thread lock-free pools are deferred
+// to a future optimization patch.
+//
+// AddressSanitizer note: The trampoline code region is allocated via
+// mmap (not malloc/new), so ASan does not track it. The data region
+// and handles are allocated via malloc (through AllocateMemoryOrCrash),
+// which ASan intercepts normally. No special annotations are needed.
+//
+// See flang/docs/InternalProcedureTrampolines.md for design details.
----------------
Saieiei wrote:
Thanks for pointing this out. The implementation uses a self-contained fixed pool rather than libffi’s trampoline-table approach. I’ll update the documentation to reflect the current behavior, including `scratch`. think an alternative trampoline design would be better discussed and evaluated as a separate follow-up. For transparency, AI tooling assisted with parts of this change.
https://github.com/llvm/llvm-project/pull/183108
More information about the flang-commits
mailing list