Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

unw_resume(3) [debian man page]

UNW_RESUME(3)						       Programming Library						     UNW_RESUME(3)

NAME
unw_resume -- resume execution in a particular stack frame SYNOPSIS
#include <libunwind.h> int unw_resume(unw_cursor_t *cp); DESCRIPTION
The unw_resume() routine resumes execution at the stack frame identified by cp. The behavior of this routine differs slightly for local and remote unwinding. For local unwinding, unw_resume() restores the machine state and then directly resumes execution in the target stack frame. Thus unw_resume() does not return in this case. Restoring the machine state normally involves restoring the ``preserved'' (callee-saved) regis- ters. However, if execution in any of the stack frames younger (more deeply nested) than the one identified by cp was interrupted by a sig- nal, then unw_resume() will restore all registers as well as the signal mask. Attempting to call unw_resume() on a cursor which identifies the stack frame of another thread results in undefined behavior (e.g., the program may crash). For remote unwinding, unw_resume() installs the machine state identified by the cursor by calling the access_reg and access_fpreg accessor callbacks as needed. Once that is accomplished, the resume accessor callback is invoked. The unw_resume routine then returns normally (that is, unlikely for local unwinding, unw_resume will always return for remote unwinding). Most platforms reserve some registers to pass arguments to exception handlers (e.g., IA-64 uses r15-r18 for this purpose). These registers are normally treated like ``scratch'' registers. However, if libunwind is used to set an exception argument register to a particular value (e.g., via unw_set_reg()), then unw_resume() will install this value as the contents of the register. In other words, the exception han- dling arguments are installed even in cases where normally only the ``preserved'' registers are restored. Note that unw_resume() does not invoke any unwind handlers (aka, ``personality routines''). If a program needs this, it will have to do so on its own by obtaining the unw_proc_info_t of each unwound frame and appropriately processing its unwind handler and language-specific data area (lsda). These steps are generally dependent on the target-platform and are regulated by the processor-specific ABI (applica- tion-binary interface). RETURN VALUE
For local unwinding, unw_resume() does not return on success. For remote unwinding, it returns 0 on success. On failure, the negative value of one of the errors below is returned. THREAD AND SIGNAL SAFETY
unw_resume() is thread-safe. If cursor cp is in the local address-space, this routine is also safe to use from a signal handler. ERRORS
UNW_EUNSPEC An unspecified error occurred. UNW_EBADREG A register needed by unw_resume() wasn't accessible. UNW_EINVALIDIP The instruction pointer identified by cp is not valid. UNW_BADFRAME The stack frame identified by cp is not valid. SEE ALSO
libunwind(3), unw_set_reg(3), sigprocmask(2) AUTHOR
David Mosberger-Tang Email: dmosberger@gmail.com WWW: http://www.nongnu.org/libunwind/. Programming Library 16 August 2007 UNW_RESUME(3)

Check Out this Related Man Page

UNW_GET_PROC_NAME(3)					       Programming Library					      UNW_GET_PROC_NAME(3)

NAME
unw_get_proc_name -- get name of current procedure SYNOPSIS
#include <libunwind.h> int unw_get_proc_name(unw_cursor_t *cp, char *bufp, size_t len, unw_word_t *offp); DESCRIPTION
The unw_get_proc_name() routine returns the name of the procedure that created the stack frame identified by argument cp. The bufp argu- ment is a pointer to a character buffer that is at least len bytes long. This buffer is used to return the name of the procedure. The offp argument is a pointer to a word that is used to return the byte-offset of the instruction-pointer saved in the stack frame identified by cp, relative to the start of the procedure. For example, if procedure foo() starts at address 0x40003000, then invoking unw_get_proc_name() on a stack frame with an instruction-pointer value of 0x40003080 would return a value of 0x80 in the word pointed to by offp (assuming the procedure is at least 0x80 bytes long). Note that on some platforms there is no reliable way to distinguish between procedure names and ordinary labels. Furthermore, if symbol information has been stripped from a program, procedure names may be completely unavailable or may be limited to those exported via a dynamic symbol table. In such cases, unw_get_proc_name() may return the name of a label or a preceeding (nearby) procedure. However, the offset returned through offp is always relative to the returned name, which ensures that the value (address) of the returned name plus the returned offset will always be equal to the instruction-pointer of the stack frame identified by cp. RETURN VALUE
On successful completion, unw_get_proc_name() returns 0. Otherwise the negative value of one of the error-codes below is returned. THREAD AND SIGNAL SAFETY
unw_get_proc_name() is thread-safe. If cursor cp is in the local address-space, this routine is also safe to use from a signal handler. ERRORS
UNW_EUNSPEC An unspecified error occurred. UNW_ENOINFO Libunwind was unable to determine the name of the procedure. UNW_ENOMME The procedure name is too long to fit in the buffer provided. A truncated version of the name has been returned. In addition, unw_get_proc_name() may return any error returned by the access_mem() call-back (see unw_create_addr_space(3)). SEE ALSO
libunwind(3), unw_get_proc_info(3) AUTHOR
David Mosberger-Tang Email: dmosberger@gmail.com WWW: http://www.nongnu.org/libunwind/. Programming Library 16 August 2007 UNW_GET_PROC_NAME(3)
Man Page