Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

stack(5) [bsd man page]

STACK(5)							File Formats Manual							  STACK(5)

stack - 2.10BSD PDP-11 C stack frame conventions DESCRIPTION
The standard C stack frame layout: ------------------ |...nth argument | push arguments in reverse order ------------------ |second argument | ------------------ | first argument | ------------------ JSR PC,*$_FOO | return address | ------------------ JSR R5,CSV | old R5 value | <----- ------------------ | |previous overlay| | | number | | ------------------ | | r4 | | ------------------ | | r3 | | ------------------ | | r2 | | ------------------ | | first local var| | This is the top of the stack ------------------ | when the called routine ``starts'' | routine | | | allocates | | | storage | | SUB $n,SP | temporary | | ------------------ | | push arguments | | | of next routine| | ------------------ | JSR PC,*$_BAR | return address | | ------------------ | JSR R5,CSV | old R5 value---+------- ------------------ ^ |previous overlay| | | number | | ------------------ | | r4/43/r2/... | | ------------------ | and so on..... | The stack pushes downward through memory addresses. Overlay numbers saved in non-overlaid objects are always zero, but the simplification of not having to maintain two different stack frame formats more than outweighs the extra few micro seconds (less than four) necessary to save the zero ... Functions returning integers leave their return value in R0; functions returning floating constants use FR0; functions returning longs leave return values in R1/R0 (R0 high word, R1 low); functions returning structures leave a pointer to bss storage (one chunk of which is allocated for each such routine) in R0, and the caller will copy from that bss storage to the local destination. Local variables are allocated in such a way that they are referred to as ``-N(R5)'', arguments are referred to as ``+N(R5)''; arguments start at 4(R5), the first integer local declared will be at -10(R5). The SP normally points at the first word available for parameter pushing. A function taking only single word as a parameter can be called simply by moving the parameter into (SP) and calling the function, without having to clean the parameter off the stack on return. Any parameters passed after the first (actually "Nth") must be pushed before the call and cleaned off afterwards. If the function has no local variables and calls no functions, it will allocate no stack and the word labelled ``first local var'' will be unused. It is important to note that routines know how many arguments they pass to a function, and will adjust the stack accordingly after a func- tion returns. NOTE
This stack frame format is the same as that used by overlaid objects in 2.9BSD. AUTHOR
John F. Woods, MIT Concouse Computer Center 3rd Berkeley Distribution STACK(5)

Check Out this Related Man Page

STACK(9)						   BSD Kernel Developer's Manual						  STACK(9)

stack -- kernel thread stack tracing routines SYNOPSIS
#include <sys/param.h> #include <sys/stack.h> In the kernel configuration file: options DDB options STACK struct stack * stack_create(void); void stack_destroy(struct stack *st); int stack_put(struct stack *st, vm_offset_t pc); void stack_copy(struct stack *src, struct stack dst); void stack_zero(struct stack *st); void stack_print(struct stack *st); void stack_print_ddb(struct stack *st); void stack_print_short(struct stack *st); void stack_print_short_ddb(struct stack *st); void stack_sbuf_print(struct sbuf sb*, struct stack *st); void stack_sbuf_print_ddb(struct sbuf sb*, struct stack *st); void stack_save(struct stack *st); DESCRIPTION
The stack KPI allows querying of kernel stack trace information and the automated generation of kernel stack trace strings for the purposes of debugging and tracing. To use the KPI, at least one of options DDB and options STACK must be compiled into the kernel. Each stack trace is described by a struct stack. Before a trace may be created or otherwise manipulated, storage for the trace must be allo- cated with stack_create(), which may sleep. Memory associated with a trace is freed by calling stack_destroy(). A trace of the current kernel thread's call stack may be captured using stack_save(). stack_print() and stack_print_short() may be used to print a stack trace using the kernel printf(9), and may sleep as a result of acquiring sx(9) locks in the kernel linker while looking up symbol names. In locking-sensitive environments, the unsynchronized stack_print_ddb() and stack_print_short_ddb() variants may be invoked. This function bypasses kernel linker locking, making it usable in ddb(4), but not in a live system where linker data structures may change. stack_sbuf_print() may be used to construct a human-readable string, including conversion (where possible) from a simple kernel instruction pointer to a named symbol and offset. The argument sb must be an initialized struct sbuf as described in sbuf(9). This function may sleep if an auto-extending struct sbuf is used, or due to kernel linker locking. In locking-sensitive environments, such as ddb(4), the unsynchro- nized stack_sbuf_print_ddb() variant may be invoked to avoid kernel linker locking; it should be used with a fixed-length sbuf. The utility functions stack_zero, stack_copy, and stack_put may be used to manipulate stack data structures directly. SEE ALSO
ddb(4), printf(9), sbuf(9), sx(9) AUTHORS
The stack(9) function suite was created by Antoine Brodin. stack(9) was extended by Robert Watson for general-purpose use outside of ddb(4). BSD
June 24, 2009 BSD
Man Page

Featured Tech Videos