From e7e4125b9afcdd522035d3ba91503c27a548e72d Mon Sep 17 00:00:00 2001 From: Lang Hames Date: Wed, 24 Feb 2021 07:27:39 +1100 Subject: [PATCH] Revert "[docs][ORC] Fix section title and reference." This reverts commit 6e1affe71c79a1cb5ea9d805ff7baae5cba59c0e, which caused an error on the Sphinx doc bot. --- docs/ORCv2.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/ORCv2.rst b/docs/ORCv2.rst index 8489dd8cf0e..cfd09ba0e22 100644 --- a/docs/ORCv2.rst +++ b/docs/ORCv2.rst @@ -324,13 +324,13 @@ to be re-used across JIT sessions as the JIT'd code no longer changes, only the absolute symbol definition does. For process and library symbols the DynamicLibrarySearchGenerator utility (See -:ref:`How to Add Process and Library Symbols to JITDylibs`) can be used to -automatically build absolute symbol mappings for you. However the -absoluteSymbols function is still useful for making non-global objects in your -JIT visible to JIT'd code. For example, imagine that your JIT standard library -needs access to your JIT object to make some calls. We could bake the address of -your object into the library, but then it would need to be recompiled for each -session: +:ref:`How to Add Process and Library Symbols to JITDylibs +`) can be used to automatically build absolute +symbol mappings for you. However the absoluteSymbols function is still useful +for making non-global objects in your JIT visible to JIT'd code. For example, +imagine that your JIT standard library needs access to your JIT object to make +some calls. We could bake the address of your object into the library, but then +it would need to be recompiled for each session: .. code-block: c++ @@ -683,8 +683,8 @@ all modules on the same context: .. _ProcessAndLibrarySymbols: -How to Add Process and Library Symbols to JITDylibs -=================================================== +How to Add Process and Library Symbols to the JITDylibs +======================================================= JIT'd code typically needs access to symbols in the host program or in supporting libraries. References to process symbols can be "baked in" to code