1\documentclass{article} 2\usepackage[fancyhdr,pdf]{latex2man} 3 4\input{common.tex} 5 6\begin{document} 7 8\begin{Name}{3}{libunwind}{David Mosberger-Tang}{Programming Library}{Introduction to libunwind}libunwind -- a (mostly) platform-independent unwind API 9\end{Name} 10 11\section{Synopsis} 12 13\File{\#include $<$libunwind.h$>$}\\ 14 15\noindent 16\Type{int} \Func{unw\_getcontext}(\Type{unw\_context\_t~*});\\ 17\noindent 18\Type{int} \Func{unw\_init\_local}(\Type{unw\_cursor\_t~*}, \Type{unw\_context\_t~*});\\ 19\noindent 20\Type{int} \Func{unw\_init\_remote}(\Type{unw\_cursor\_t~*}, \Type{unw\_addr\_space\_t}, \Type{void~*});\\ 21\noindent 22\Type{int} \Func{unw\_step}(\Type{unw\_cursor\_t~*});\\ 23\noindent 24\Type{int} \Func{unw\_get\_reg}(\Type{unw\_cursor\_t~*}, \Type{unw\_regnum\_t}, \Type{unw\_word\_t~*});\\ 25\noindent 26\Type{int} \Func{unw\_get\_fpreg}(\Type{unw\_cursor\_t~*}, \Type{unw\_regnum\_t}, \Type{unw\_fpreg\_t~*});\\ 27\noindent 28\Type{int} \Func{unw\_set\_reg}(\Type{unw\_cursor\_t~*}, \Type{unw\_regnum\_t}, \Type{unw\_word\_t});\\ 29\noindent 30\Type{int} \Func{unw\_set\_fpreg}(\Type{unw\_cursor\_t~*}, \Type{unw\_regnum\_t}, \Type{unw\_fpreg\_t});\\ 31\noindent 32\Type{int} \Func{unw\_resume}(\Type{unw\_cursor\_t~*});\\ 33 34\noindent 35\Type{unw\_addr\_space\_t} \Var{unw\_local\_addr\_space};\\ 36\noindent 37\Type{unw\_addr\_space\_t} \Func{unw\_create\_addr\_space}(\Type{unw\_accessors\_t}, \Type{int});\\ 38\noindent 39\Type{void} \Func{unw\_destroy\_addr\_space}(\Type{unw\_addr\_space\_t});\\ 40\noindent 41\Type{unw\_accessors\_t} \Func{unw\_get\_accessors}(\Type{unw\_addr\_space\_t});\\ 42\noindent 43\Type{void} \Func{unw\_flush\_cache}(\Type{unw\_addr\_space\_t}, \Type{unw\_word\_t}, \Type{unw\_word\_t});\\ 44\noindent 45\Type{int} \Func{unw\_set\_caching\_policy}(\Type{unw\_addr\_space\_t}, \Type{unw\_caching\_policy\_t});\\ 46\noindent 47\Type{int} \Func{unw\_set\_cache\_size}(\Type{unw\_addr\_space\_t}, \Type{size\_t}, \Type{int});\\ 48 49\noindent 50\Type{const char *}\Func{unw\_regname}(\Type{unw\_regnum\_t});\\ 51\noindent 52\Type{int} \Func{unw\_get\_proc\_info}(\Type{unw\_cursor\_t~*}, \Type{unw\_proc\_info\_t~*});\\ 53\noindent 54\Type{int} \Func{unw\_get\_save\_loc}(\Type{unw\_cursor\_t~*}, \Type{int}, \Type{unw\_save\_loc\_t~*});\\ 55\noindent 56\Type{int} \Func{unw\_is\_fpreg}(\Type{unw\_regnum\_t});\\ 57\Type{int} \Func{unw\_is\_signal\_frame}(\Type{unw\_cursor\_t~*});\\ 58\noindent 59\Type{int} \Func{unw\_get\_proc\_name}(\Type{unw\_cursor\_t~*}, \Type{char~*}, \Type{size\_t}, \Type{unw\_word\_t~*});\\ 60 61\noindent 62\Type{void} \Func{\_U\_dyn\_register}(\Type{unw\_dyn\_info\_t~*});\\ 63\noindent 64\Type{void} \Func{\_U\_dyn\_cancel}(\Type{unw\_dyn\_info\_t~*});\\ 65 66\section{Local Unwinding} 67 68\Prog{Libunwind} is very easy to use when unwinding a stack from 69within a running program. This is called \emph{local} unwinding. Say 70you want to unwind the stack while executing in some function 71\Func{F}(). In this function, you would call \Func{unw\_getcontext}() 72to get a snapshot of the CPU registers (machine-state). Then you 73initialize an \emph{unwind~cursor} based on this snapshot. This is 74done with a call to \Func{unw\_init\_local}(). The cursor now points 75to the current frame, that is, the stack frame that corresponds to the 76current activation of function \Func{F}(). The unwind cursor can then 77be moved ``up'' (towards earlier stack frames) by calling 78\Func{unw\_step}(). By repeatedly calling this routine, you can 79uncover the entire call-chain that led to the activation of function 80\Func{F}(). A positive return value from \Func{unw\_step}() indicates 81that there are more frames in the chain, zero indicates that the end 82of the chain has been reached, and any negative value indicates that 83some sort of error has occurred. 84 85While it is not possible to directly move the unwind cursor in the 86``down'' direction (towards newer stack frames), this effect can be 87achieved by making copies of an unwind cursor. For example, a program 88that sometimes has to move ``down'' by one stack frame could maintain 89two cursor variables: ``\Var{curr}'' and ``\Var{prev}''. The former 90would be used as the current cursor and \Var{prev} would be maintained 91as the ``previous frame'' cursor by copying the contents of \Var{curr} 92to \Var{prev} right before calling \Func{unw\_step}(). With this 93approach, the program could move one step ``down'' simply by copying 94back \Var{prev} to \Var{curr} whenever that is necessary. In the most 95extreme case, a program could maintain a separate cursor for each call 96frame and that way it could move up and down the callframe-chain at 97will. 98 99Given an unwind cursor, it is possible to read and write the CPU 100registers that were preserved for the current stack frame (as 101identified by the cursor). \Prog{Libunwind} provides several routines 102for this purpose: \Func{unw\_get\_reg}() reads an integer (general) 103register, \Func{unw\_get\_fpreg}() reads a floating-point register, 104\Func{unw\_set\_reg}() writes an integer register, and 105\Func{unw\_set\_fpreg}() writes a floating-point register. Note that, 106by definition, only the \emph{preserved} machine state can be accessed 107during an unwind operation. Normally, this state consists of the 108\emph{callee-saved} (``preserved'') registers. However, in some 109special circumstances (e.g., in a signal handler trampoline), even the 110\emph{caller-saved} (``scratch'') registers are preserved in the stack 111frame and, in those cases, \Prog{libunwind} will grant access to them 112as well. The exact set of registers that can be accessed via the 113cursor depends, of course, on the platform. However, there are two 114registers that can be read on all platforms: the instruction pointer 115(IP), sometimes also known as the ``program counter'', and the stack 116pointer (SP). In \Prog{libunwind}, these registers are identified by 117the macros \Const{UNW\_REG\_IP} and \Const{UNW\_REG\_SP}, 118respectively. 119 120Besides just moving the unwind cursor and reading/writing saved 121registers, \Prog{libunwind} also provides the ability to resume 122execution at an arbitrary stack frame. As you might guess, this is 123useful for implementing non-local gotos and the exception handling 124needed by some high-level languages such as Java. Resuming execution 125with a particular stack frame simply requires calling 126\Func{unw\_resume}() and passing the cursor identifying the target 127frame as the only argument. 128 129Normally, \Prog{libunwind} supports both local and remote unwinding 130(the latter will be explained in the next section). However, if you 131tell libunwind that your program only needs local unwinding, then a 132special implementation can be selected which may run much faster than 133the generic implementation which supports both kinds of unwinding. To 134select this optimized version, simply define the macro 135\Const{UNW\_LOCAL\_ONLY} before including the headerfile 136\File{$<$libunwind.h$>$}. It is perfectly OK for a single program to 137employ both local-only and generic unwinding. That is, whether or not 138\Const{UNW\_LOCAL\_ONLY} is defined is a choice that each source-file 139(compilation-unit) can make on its own. Independent of the setting(s) 140of \Const{UNW\_LOCAL\_ONLY}, you'll always link the same library into 141the program (normally \Opt{-l}\File{unwind}). Furthermore, the 142portion of \Prog{libunwind} that manages unwind-info for dynamically 143generated code is not affected by the setting of 144\Const{UNW\_LOCAL\_ONLY}. 145 146If we put all of the above together, here is how we could use 147\Prog{libunwind} to write a function ``\Func{show\_backtrace}()'' 148which prints a classic stack trace: 149 150\begin{verbatim} 151#define UNW_LOCAL_ONLY 152#include <libunwind.h> 153 154void show_backtrace (void) { 155 unw_cursor_t cursor; unw_context_t uc; 156 unw_word_t ip, sp; 157 158 unw_getcontext(&uc); 159 unw_init_local(&cursor, &uc); 160 while (unw_step(&cursor) > 0) { 161 unw_get_reg(&cursor, UNW_REG_IP, &ip); 162 unw_get_reg(&cursor, UNW_REG_SP, &sp); 163 printf ("ip = %lx, sp = %lx\n", (long) ip, (long) sp); 164 } 165} 166\end{verbatim} 167 168 169\section{Remote Unwinding} 170 171\Prog{Libunwind} can also be used to unwind a stack in a ``remote'' 172process. Here, ``remote'' may mean another process on the same 173machine or even a process on a completely different machine from the 174one that is running \Prog{libunwind}. Remote unwinding is typically 175used by debuggers and instruction-set simulators, for example. 176 177Before you can unwind a remote process, you need to create a new 178address-space object for that process. This is achieved with the 179\Func{unw\_create\_addr\_space}() routine. The routine takes two 180arguments: a pointer to a set of \emph{accessor} routines and an 181integer that specifies the byte-order of the target process. The 182accessor routines provide \Func{libunwind} with the means to 183communicate with the remote process. In particular, there are 184callbacks to read and write the process's memory, its registers, and 185to access unwind information which may be needed by \Func{libunwind}. 186 187With the address space created, unwinding can be initiated by a call 188to \Func{unw\_init\_remote}(). This routine is very similar to 189\Func{unw\_init\_local}(), except that it takes an address-space 190object and an opaque pointer as arguments. The routine uses these 191arguments to fetch the initial machine state. \Prog{Libunwind} never 192uses the opaque pointer on its own, but instead just passes it on to 193the accessor (callback) routines. Typically, this pointer is used to 194select, e.g., the thread within a process that is to be unwound. 195 196Once a cursor has been initialized with \Func{unw\_init\_remote}(), 197unwinding works exactly like in the local case. That is, you can use 198\Func{unw\_step}() to move ``up'' in the call-chain, read and write 199registers, or resume execution at a particular stack frame by calling 200\Func{unw\_resume}. 201 202 203\section{Cross-platform and Multi-platform Unwinding} 204 205\Prog{Libunwind} has been designed to enable unwinding across 206platforms (architectures). Indeed, a single program can use 207\Prog{libunwind} to unwind an arbitrary number of target platforms, 208all at the same time! 209 210We call the machine that is running \Prog{libunwind} the \emph{host} 211and the machine that is running the process being unwound the 212\emph{target}. If the host and the target platform are the same, we 213call it \emph{native} unwinding. If they differ, we call it 214\emph{cross-platform} unwinding. 215 216The principle behind supporting native, cross-platform, and 217multi-platform unwinding is very simple: for native unwinding, a 218program includes \File{$<$libunwind.h$>$} and uses the linker switch 219\Opt{-l}\File{unwind}. For cross-platform unwinding, a program 220includes \File{$<$libunwind-}\Var{PLAT}\File{.h$>$} and uses the linker 221switch \Opt{-l}\File{unwind-}\Var{PLAT}, where \Var{PLAT} is the name 222of the target platform (e.g., \File{ia64} for IA-64, \File{hppa-elf} 223for ELF-based HP PA-RISC, or \File{x86} for 80386). Multi-platform 224unwinding works exactly like cross-platform unwinding, the only 225limitation is that a single source file (compilation unit) can include 226at most one \Prog{libunwind} header file. In other words, the 227platform-specific support for each supported target needs to be 228isolated in separate source files---a limitation that shouldn't be an 229issue in practice. 230 231Note that, by definition, local unwinding is possible only for the 232native case. Attempting to call, e.g., \Func{unw\_local\_init}() when 233targeting a cross-platform will result in a link-time error 234(unresolved references). 235 236 237\section{Thread- and Signal-Safety} 238 239 240All \Prog{libunwind} routines are thread-safe. What this means is 241that multiple threads may use \Prog{libunwind} simulatenously. 242However, any given cursor may be accessed by only one thread at 243any given time. 244 245To ensure thread-safety, some \Prog{libunwind} routines may have to 246use locking. Such routines \emph{must~not} be called from signal 247handlers (directly or indirectly) and are therefore \emph{not} 248signal-safe. The manual page for each \Prog{libunwind} routine 249identifies whether or not it is signal-safe, but as a general rule, 250any routine that may be needed for \emph{local} unwinding is 251signal-safe (e.g., \Func{unw\_step}() for local unwinding is 252signal-safe). For remote-unwinding, \emph{none} of the 253\Prog{libunwind} routines are guaranteed to be signal-safe. 254 255 256\section{Unwinding Through Dynamically Generated Code} 257 258\Func{Libunwind} provides the routines \Func{\_U\_dyn\_register}() and 259\Func{\_U\_dyn\_cancel}() to register/cancel the information required to 260unwind through code that has been generated at runtime (e.g., by a 261just-in-time (JIT) compiler). It is important to register the 262information for \emph{all} dynamically generated code because 263otherwise, a debugger may not be able to function properly or 264high-level language exception handling may not work as expected. 265 266The interface for registering and canceling dynamic unwind info has 267been designed for maximum efficiency, so as to minimize the 268performance impact on JIT-compilers. In particular, both routines are 269guaranteed to execute in ``constant time'' (O(1)) and the 270data-structure encapsulating the dynamic unwind info has been designed 271to facilitate sharing, such that similar procedures can share much of 272the underlying information. 273 274For more information on the \Prog{libunwind} support for dynamically 275generated code, see \SeeAlso{libunwind-dynamic(3)}. 276 277 278\section{Caching of Unwind Info} 279 280To speed up execution, \Prog{libunwind} may aggressively cache the 281information it needs to perform unwinding. If a process changes 282during its lifetime, this creates a risk of \Prog{libunwind} using 283stale data. For example, this would happen if \Prog{libunwind} were 284to cache information about a shared library which later on gets 285unloaded (e.g., via \Cmd{dlclose}{3}). 286 287To prevent the risk of using stale data, \Prog{libunwind} provides two 288facilities: first, it is possible to flush the cached information 289associated with a specific address range in the target process (or the 290entire address space, if desired). This functionality is provided by 291\Func{unw\_flush\_cache}(). The second facility is provided by 292\Func{unw\_set\_caching\_policy}(), which lets a program 293select the exact caching policy in use for a given address-space 294object. In particular, by selecting the policy 295\Const{UNW\_CACHE\_NONE}, it is possible to turn off caching 296completely, therefore eliminating the risk of stale data alltogether 297(at the cost of slower execution). By default, caching is enabled for 298local unwinding only. The cache size can be dynamically changed with 299\Func{unw\_set\_cache\_size}(), which also fluches the current cache. 300 301 302\section{Files} 303 304\begin{Description} 305\item[\File{libunwind.h}] Headerfile to include for native (same 306 platform) unwinding. 307\item[\File{libunwind-}\Var{PLAT}\File{.h}] Headerfile to include when 308 the unwind target runs on platform \Var{PLAT}. For example, to unwind 309 an IA-64 program, the header file \File{libunwind-ia64.h} should be 310 included. 311\item[\Opt{-l}\File{unwind}] Linker-switch to add when building a 312 program that does native (same platform) unwinding. 313\item[\Opt{-l}\File{unwind-}\Var{PLAT}] Linker-switch to add when 314 building a program that unwinds a program on platform \Var{PLAT}. 315 For example, to (cross-)unwind an IA-64 program, the linker switch 316 \File{-lunwind-ia64} should be added. Note: multiple such switches 317 may need to be specified for programs that can unwind programs on 318 multiple platforms. 319\end{Description} 320 321\section{See Also} 322 323\SeeAlso{libunwind-dynamic(3)}, 324\SeeAlso{libunwind-ia64(3)}, 325\SeeAlso{libunwind-ptrace(3)}, 326\SeeAlso{libunwind-setjmp(3)}, 327\SeeAlso{unw\_create\_addr\_space(3)}, 328\SeeAlso{unw\_destroy\_addr\_space(3)}, 329\SeeAlso{unw\_flush\_cache(3)}, 330\SeeAlso{unw\_get\_accessors(3)}, 331\SeeAlso{unw\_get\_fpreg(3)}, 332\SeeAlso{unw\_get\_proc\_info(3)}, 333\SeeAlso{unw\_get\_proc\_name(3)}, 334\SeeAlso{unw\_get\_reg(3)}, 335\SeeAlso{unw\_getcontext(3)}, 336\SeeAlso{unw\_init\_local(3)}, 337\SeeAlso{unw\_init\_remote(3)}, 338\SeeAlso{unw\_is\_fpreg(3)}, 339\SeeAlso{unw\_is\_signal\_frame(3)}, 340\SeeAlso{unw\_regname(3)}, 341\SeeAlso{unw\_resume(3)}, 342\SeeAlso{unw\_set\_caching\_policy(3)}, 343\SeeAlso{unw\_set\_cache\_size(3)}, 344\SeeAlso{unw\_set\_fpreg(3)}, 345\SeeAlso{unw\_set\_reg(3)}, 346\SeeAlso{unw\_step(3)}, 347\SeeAlso{unw\_strerror(3)}, 348\SeeAlso{\_U\_dyn\_register(3)}, 349\SeeAlso{\_U\_dyn\_cancel(3)} 350 351\section{Author} 352 353\noindent 354David Mosberger-Tang\\ 355Email: \Email{dmosberger@gmail.com}\\ 356WWW: \URL{http://www.nongnu.org/libunwind/}. 357\LatexManEnd 358 359\end{document} 360