Home | History | Annotate | Download | only in docs

Lines Matching full:stack

28 :ref:`processor stack and registers <gcroot>`.
89 * Computation of the stack map. For each safe point in the code, object
90 references within the stack frame must be identified so that the collector may
103 * Registration of stack map entries with the runtime.
128 #. Design a binary interface for the stack map, used to identify references
129 within a stack frame on the machine stack.\*
131 #. Implement a stack crawler to discover functions on the call stack.\*
147 * Use ``@llvm.gcroot`` to mark stack roots.
162 * Compile LLVM's stack map to the binary form expected by the runtime.
176 To turn the shadow stack on for your functions, first call:
180 F.setGC("shadow-stack");
182 for each function your compiler emits. Since the shadow stack is built into
197 The shadow stack doesn't imply a memory allocation algorithm. A semispace
201 When it comes time to collect, however, your runtime needs to traverse the stack
202 roots, and for this it needs to integrate with the shadow stack. Luckily, doing
208 /// @brief The map for a single function's stack frame. One of these is
214 int32_t NumRoots; //< Number of roots in stack frame.
219 /// @brief A link in the dynamic shadow stack. One of these is embedded in
220 /// the stack frame of each function on the call stack.
222 StackEntry *Next; //< Link to next stack entry (the caller's).
224 void *Roots[0]; //< Stack roots (in-place array).
233 /// @brief Calls Visitor(root, meta) for each GC root on the stack.
240 /// @param Visitor A function to invoke for every GC root on the stack.
255 About the shadow stack
259 stack maps, this algorithm carefully maintains a linked list of stack roots
260 [:ref:`Henderson2002 <henderson02>`]. This so-called "shadow stack" mirrors the
261 machine stack. Maintaining this data structure is slower than using a stack map
264 and does not require tricky platform-specific code to crawl the machine stack.
311 Identifying GC roots on the stack: ``llvm.gcroot``
318 The ``llvm.gcroot`` intrinsic is used to inform LLVM that a stack variable
330 case that ``g()`` triggers a collection. Note, that stack variables must be
340 its value will be tracked along with the location of the pointer in the stack
359 ;; stack space for X, which is an LLVM pointer.
362 ;; Tell LLVM that the stack space is a stack root.
460 stack map to assembly code (using the binary representation expected by the
466 to the binary interface defined by library, most essentially the :ref:`stack map
467 <stack-map>`.
501 * The stack map is not compiled into the executable.
552 | | | stack | | sweep | | | | |
554 | stack map | |v| | | | |x| | |x| | |x| | |x| | |x| |
611 Shadow Stack
612 The mutator carefully maintains a linked list of stack roots.
655 Computing stack maps
658 LLVM automatically computes a stack map. One of the most important features
662 The stack map consists of the location and identity of each GC root in the
674 * ``getFrameSize()``: The overall size of the function's initial stack frame,
679 To access the stack map, use ``GCFunctionMetadata::roots_begin()`` and
699 custom lowering pass, LLVM will compute an empty stack map. This may be useful
700 for collector plugins which implement reference counting or a shadow stack.
719 distinguishing an uninitialized stack root from an initialized one. Therefore,
725 For GCs which use barriers or unusual treatment of stack roots, these flags
747 * ``llvm.gcroot``: Leave it alone. The code generator must see it or the stack
868 LLVM stack map into assembly code. (At the beginning, this information is not
911 assembly code to the ``std::ostream``. The collector itself contains the stack
962 // Emit the symbol by which the stack map entry can be found.
986 // Emit the stack frame size.
988 AP.EOL("stack frame size");
998 // Print its offset within the stack frame.
1000 AP.EOL("stack offset");