Lines Matching +full:batch +full:- +full:reduce
11 This document aims to provide a high-level overview of the design and API
25 static constructors, eh-frame registration for exceptions, and TLV support for
26 thread locals; Swift and Objective-C require language runtime registration for
34 1. Cross-process and cross-architecture linking of single relocatable objects
57 --------------------------
64 .. code-block:: c++
74 .. code-block:: c++
82 .. code-block:: c++
90 .. code-block:: c++
98 .. code-block:: c++
106 .. code-block:: c++
115 can be implemented as no-ops returning ``Error::success()``.
120 .. code-block:: c++
127 // Add passes to print the set of defined symbols after dead-stripping.
149 if (Sym->hasName())
150 dbgs() << Sym->getName() << "\n";
166 OLL->addPlugin(std::make_unique<MyPlugin>());
174 ExitOnErr(J->addObject(loadFromDisk("main.o")));
177 auto MainSym = J->lookup("main");
199 * ``Addressable`` -- A node in the link graph that can be assigned an address
206 * ``Block`` -- An ``Addressable`` node that has ``Content`` (or is marked as
207 zero-filled), a parent ``Section``, a ``Size``, an ``Alignment`` (and an
217 and not for zero-fill blocks (use ``isZeroFill`` to check, and prefer
219 zero-fill and content blocks).
226 ``getSize`` method for both content and zero-filled blocks.
235 whose minimum alignment requirement comes from data at some non-zero offset
237 alignment) followed by a uint64_t (with 8-byte alignment), then the block
238 will have 8-byte alignment with an alignment offset of 7.
243 * ``Symbol`` -- An offset from an ``Addressable`` (often a ``Block``), with an
268 automate the introduction of call-stubs for lazy compilation.
271 dead-stripping purposes (see :ref:`generic_link_algorithm`). JITLink's
272 dead-stripping algorithm will propagate liveness flags through the graph to
276 * ``Edge`` -- A quad of an ``Offset`` (implicitly from the start of the
286 * ``Kind``, accessible via ``getKind`` is a relocation type -- it describes
297 * ``Section`` -- A set of ``Symbol`` instances, plus a set of ``Block``
315 of these. The most common combinations are ``RW-`` for writable data,
316 ``R--`` for constant data, and ``R-X`` for code.
323 For the graph-theorists: The ``LinkGraph`` is bipartite, with one set of
358 * ``createZeroFillBlock`` creates a zero-fill block with the given size,
367 * ``addCommonSymbol`` convenience function for creating a zero-filled block
372 offset, size, callable-ness, and liveness.
375 offset, size, linkage, scope, callable-ness and liveness.
398 in an eh-frame section).
425 and calls the ``JITLinkContext`` object to perform a (potentially high-latency)
434 #. Run pre-prune passes.
437 ``LinkGraph`` nodes still have their original vmaddrs. A mark-live pass
445 #. Prune (dead-strip) the ``LinkGraph``.
453 #. Run post-prune passes.
455 These passes are run on the graph after dead-stripping, but before memory
477 #. Run post-allocation passes.
512 #. Run pre-fixup passes.
529 #. Run post-fixup passes.
534 Post-fixup passes can inspect blocks contents to see the exact bytes that
557 ------
566 Passes may be used by both JITLink backends (e.g. MachO/x86-64 implements GOT
573 * Relaxation optimizations -- A pre-fixup pass can inspect GOT accesses and PLT
581 .. code-block:: c++
585 for (auto &E : B->edges())
601 * Metadata registration -- Post allocation passes can be used to record the
606 .. code-block:: c++
617 * Record call sites for later mutation -- A post-allocation pass can record
623 .. code-block:: c++
629 [&](LinkGraph &G) -> Error {
640 -------------------------------------------
646 requested code model in the target process (e.g. MachO/x86-64's Small code
659 .. code-block:: c++
680 argument to manage a per-simulated-dylib memory pool (since code model
681 constraints are typically imposed on a per-dylib basis, and not across
689 responsibility for these steps, or use the ``BasicLayout`` utility to reduce
691 memory defined by permissions, alignments, content sizes, and zero-fill sizes.
698 .. code-block:: c++
724 multiple objects at the same time and this allows us to batch these requests for
727 JITLink provides a simple in-process implementation of this interface:
728 ``InProcessMemoryManager``. It allocates pages once and re-uses them as both
731 ORC provides a cross-process-capable ``MapperJITLinkMemoryManager`` that can use
732 shared memory or ORC-RPC-based communication to transfer content to the executing
736 ---------------------------------
743 trade-offs between performance and security. For example, on a system where code
749 Finally, if RWX pages are not permitted but dual-virtual-mappings of
751 as RW- in the JITLink process and R-X in the executor process, allowing
756 --------------
777 non-trivial action in the executor (e.g. running initializers, managing thread
801 ``LinkGraph`` from an in-memory buffer containing an object file. This is how
804 #. ``createLinkGraph_<Object-Format>_<Architecture>`` can be used when
807 #. ``createLinkGraph_<Object-Format>`` can be used when the object format is
821 MCJIT. In MCJIT the *RuntimeDyld* component enabled re-use of LLVM as an
822 in-memory compiler by adding an in-memory link step to the end of the usual
840 -----------
848 #. It required strong linkage and default visibility on all symbols -- behavior
868 The llvm-jitlink tool
871 The ``llvm-jitlink`` tool is a command line wrapper for the JITLink library.
876 The ``llvm-jitlink`` tool was originally designed to aid JITLink development by
880 -----------
882 By default, ``llvm-jitlink`` will link the set of objects passed on the command
885 .. code-block:: sh
887 % cat hello-world.c
895 % clang -c -o hello-world.o hello-world.c
896 % llvm-jitlink hello-world.o
900 main function using the -args option:
902 .. code-block:: sh
904 % cat print-args.c
912 % cat print-args-main.c
920 % clang -c -o print-args.o print-args.c
921 % clang -c -o print-args-main.o print-args-main.c
922 % llvm-jitlink print-args.o print-args-main.o -args a b c
927 Alternative entry points may be specified using the ``-entry <entry point
930 Other options can be found by calling ``llvm-jitlink -help``.
932 llvm-jitlink as a regression testing utility
933 --------------------------------------------
935 One of the primary aims of ``llvm-jitlink`` was to enable readable regression
938 The ``-noexec`` option tells llvm-jitlink to stop after looking up the entry
941 access to the target being linked (the ``-define-abs`` or ``-phony-externals``
944 The ``-check <check-file>`` option can be used to run a set of ``jitlink-check``
946 ``-noexec``, since the aim is to validate JIT'd memory rather than to run the
947 code and ``-noexec`` allows us to link for any supported target architecture
948 from the current process. In ``-check`` mode, ``llvm-jitlink`` will scan the
949 given check-file for lines of the form ``# jitlink-check: <expr>``. See
952 Remote execution via llvm-jitlink-executor
953 ------------------------------------------
955 By default ``llvm-jitlink`` will link the given objects into its own process,
958 The ``-oop-executor[=/path/to/executor]`` option tells ``llvm-jitlink`` to
959 execute the given executor (which defaults to ``llvm-jitlink-executor``) and
961 as the first argument with the format ``filedescs=<in-fd>,<out-fd>``.
963 The ``-oop-executor-connect=<host>:<port>`` option tells ``llvm-jitlink`` to
965 use this option you will need to start ``llvm-jitlink-executor`` manually with
969 ------------
971 The ``-harness`` option allows a set of input objects to be designated as a test
977 ``llvm-jitlink`` when it sees the ``-harness`` option).
984 .. code-block:: c
1001 .. code-block:: c
1019 However, using ``-harness`` and ``-phony-externals`` we can run this code
1022 .. code-block:: sh
1024 % clang -c -o test_code_harness.o test_code_harness.c
1025 % llvm-jitlink -phony-externals test_code.o -harness test_code_harness.o
1029 The ``-harness`` option may be of interest to people who want to perform some
1033 classes tends to have a lot of non-trivial surface area (e.g. vtables) that
1037 -----------------------------------
1046 #. Don't assume you're linking in-process. Use libSupport's sized,
1047 endian-specific types when reading/writing content in the ``LinkGraph``.
1049 As a "minimum viable" JITLink wrapper, the ``llvm-jitlink`` tool is an
1056 In debug builds of LLVM, the ``-debug-only=jitlink`` option dumps logs from the
1058 a glance. The ``-debug-only=llvm_jitlink`` option dumps logs from the ``llvm-jitlink``
1060 ``-debug-only=jitlink``) and the tool itself.
1062 The ``-oop-executor`` and ``-oop-executor-connect`` options are helpful for testing
1063 handling of cross-process and cross-architecture use cases.
1069 implementation. In LLVM 12 there is limited support for ELF on x86-64.
1081 file, and tied to the x86-64 relocation parsing code. The bulk of the code is
1090 ---------------------------------------
1110 .. list-table:: Availability and Status
1112 :header-rows: 1
1113 :stub-columns: 1
1115 * - Architecture
1116 - ELF
1117 - COFF
1118 - MachO
1119 * - arm32
1120 - Skeleton
1121 -
1122 -
1123 * - arm64
1124 - Usable
1125 -
1126 - Good
1127 * - LoongArch
1128 - Good
1129 -
1130 -
1131 * - PowerPC 64
1132 - Usable
1133 -
1134 -
1135 * - RISC-V
1136 - Good
1137 -
1138 -
1139 * - x86-32
1140 - Basic
1141 -
1142 -
1143 * - x86-64
1144 - Good
1145 - Usable
1146 - Good
1154 memory layout. Hidden symbols break this by generating in-range accesses
1156 within range of one another. That said, providing a pre-reserved address
1158 optimizations will kick in for all intra-dylib references, which is good
1160 reserving the address-range up-front).