Lines Matching +full:- +full:- +full:add +full:- +full:architecture
8 …unwind-dynamic}{David Mosberger-Tang}{Programming Library}{Introduction to dynamic unwind-info}lib…
14 the \emph{frame state} of each frame in a call-chain. The frame state
15 describes the subset of the machine-state that consists of the
16 \emph{frame registers} (typically the instruction-pointer and the
17 stack-pointer) and all callee-saved registers (preserved registers).
20 which the current value is stored (callee-saved registers).
23 emitting \emph{unwind-info} which provides the minimum amount of
24 information needed to reconstruct the frame-state for each instruction
26 generator must use the dynamic unwind-info interface provided by
32 procedure directly corresponds to a function in the source-language
34 code-generator could translate a given function into two separate
35 (discontiguous) procedures: one for frequently-executed (hot) code and
36 one for rarely-executed (cold) code. Similarly, simple
37 source-language functions (usually leaf functions) may get translated
38 into code for which the default unwind-conventions apply and for such
39 code, it is not strictly necessary to register dynamic unwind-info.
46 can be empty. If non-empty, the prologue sets up the frame state for
48 on the stack and save certain callee-saved registers. The body
50 frame state in any way. If non-empty, the epilogue restores the
56 are logically separate entities, optimizing code-generators will
58 reason, the dynamic unwind-info interface of \Prog{libunwind} makes no
62 by the dynamic unwind-info is the point at which the stack-pointer
64 once the stack-pointer is restored, all values saved in the
69 instructions which restore the contents of callee-saved registers.
74 Exactly how this index is derived depends on the architecture. For
75 example, on RISC and EPIC-style architecture, instructions have a
77 contrast, most CISC use variable-length instruction encodings, so it
78 is usually necessary to use a byte-offset as the index. Given the
81 that the instruction stores calle-saved register \Var{r1} at offset 16
86 A runtime code-generator registers the dynamic unwind-info of a
96 \item[\Type{unw\_word\_t} \Var{start\_ip}] The start-address of the
98 contiguous pieces of code, so a single code-range is sufficient).
99 \item[\Type{unw\_word\_t} \Var{end\_ip}] The end-address of the
100 instructions of the procedure (non-inclusive, that is,
101 \Var{end\_ip}-\Var{start\_ip} is the size of the procedure in
103 \item[\Type{unw\_word\_t} \Var{gp}] The global-pointer value in use
104 for this procedure. The exact meaing of the global-pointer is
105 architecture-specific and on some architecture, it is not used at
107 \item[\Type{int32\_t} \Var{format}] The format of the unwind-info.
111 \item[\Type{union} \Var{u}] This union contains one sub-member
112 structure for every possible unwind-info format:
121 The format of these sub-members is described in detail below.
124 \subsection{Proc-info format}
126 This is the preferred dynamic unwind-info format and it is generally
127 the one used by full-blown runtime code-generators. In this format,
134 (human-readable) name of the procedure or 0 if no such name is
135 available. If non-zero, The string stored at this address must be
136 ASCII NUL terminated. For source languages that use name-mangling
141 personality-routine for this procedure. Personality-routines are
143 (http://www.codesourcery.com/cxx-abi/) for an overview and a
151 \item[\Type{unw\_dyn\_region\_info\_t~*}\Var{regions}] A NULL-terminated
152 linked list of region-descriptors. See section ``Region
157 \subsection{Table-info format}
160 derived from static code and the unwind-info for the dynamic and the
162 when loading statically-generated code into an address-space in a
163 non-standard fashion (i.e., through some means other than
170 (human-readable) name of the procedure or 0 if no such name is
171 available. If non-zero, The string stored at this address must be
172 ASCII NUL terminated. For source languages that use name-mangling
176 \item[\Type{unw\_word\_t} \Var{segbase}] The segment-base value
177 that needs to be added to the segment-relative values stored in the
178 unwind-info. The exact meaning of this value is
179 architecture-specific.
182 unwind-info (\Var{table\_data}) counted in units of words
186 data encoding the unwind-info. The exact format is
187 architecture-specific (see architecture-specific sections below).
191 \subsection{Remote table-info format}
193 The remote table-info format has the same basic purpose as the regular
194 table-info format. The only difference is that when \Prog{libunwind}
195 uses the unwind-info, it will keep the table data in the target
196 address-space (which may be remote). Consequently, the type of the
198 This implies that \Prog{libunwind} will have to access the table-data
199 via the address-space's \Func{access\_mem}() call-back, rather than
202 From the point of view of a runtime-code generator, the remote
203 table-info format offers no advantage and it is expected that such
204 generators will describe their procedures either with the proc-info
205 format or the normal table-info format. The main reason that the
206 remote table-info format exists is to enable the
207 address-space-specific \Func{find\_proc\_info}() callback (see
226 architecture-specific sections for details). The value of
255 memory-allocation request. To facilitate the allocation of a region
281 predicated architecturs such as IA-64 or ARM, where the contents of
282 another (callee-saved) register determines whether or not an
289 \item[\Type{int32\_t} \Var{when}] The region-relative number of
309 but a runtime code-generator should not go to extra lengths just to
318 and if the runtime code-generator happens to generated sorted lists
330 region-descriptor are ignored. This tag is guaranteed to have a
337 spills register \Var{reg} to a frame-pointer-relative location. The
338 frame-pointer-relative offset is given by the value stored in member
339 \Var{val}. See the architecture-specific sections for a description
343 spills register \Var{reg} to a stack-pointer-relative location. The
344 stack-pointer-relative offset is given by the value stored in member
345 \Var{val}. See the architecture-specific sections for a description
349 the constant value \Var{val} to register \Var{reg}. To add subtract
350 a constant value, store the two's-complement of the value in
352 is described in the architecture-specific sections below.
376 \section{IA-64 specifics}
378 - meaning of segbase member in table-info/table-remote-info format
379 - format of table\_data in table-info/table-remote-info format
380 - instruction size: each bundle is counted as 3 instructions, regardless
382 - describe stack-frame layout, especially with regards to sp-relative
383 and fp-relative addressing
384 - UNW\_DYN\_ADD can only add to ``sp'' (always a negative value); use
396 David Mosberger-Tang\\