Background: I'm allocating my own machine contexts and stacks with the getcontext(3)
/ makecontext(3)
/ setcontext(3)
(ucontext.h
; SUSv2, POSIX.1-2001) family of functions.
When I use gdb (version 6.1.1) to examine a stack while the thread is in one of these contexts I've allocated, it seems like gdb doesn't know where the end (logical bottom) of the stack is. E.g., here's a stack from x86 FreeBSD:
#0 0x2872d79f in poll () from /lib/libc.so.7
#1 0x28646e23 in poll () from /lib/libthr.so.3
#2 0x2869b267 in fdtask (task=0x28a3dc40, v=0x0) at fd.c:58
#3 0x2869c8dc in taskstart (y=681827392, x=0) at task.c:58
#4 0x00000000 in ?? ()
#5 0x28a3dc40 in ?? ()
#6 0x00000000 in ?? ()
#7 0x00000000 in ?? ()
…
#65 0x00000000 in ?? ()
…
(Yes, this is built on top of Russ Cox' libtask library.)
This context's execution begins at the taskstart
function, but it seems like GDB can't figure out that it should stop trying to read the stack even though it hits a return address of NULL in that frame.
My question is: Is there something I can do (by formatting the stack in some way, or setting a register, anything) to help GDB understand where the top of the stack is? Thanks.
Edit: Conclusion: It appears that one way gdb 6.1.1 detects the end of the stack is by checking that the stored frame pointer is NULL; I fixed the problem for my use case by modifying the x86 and amd64 makecontext(2)
function to reset ebp or rbp to zero when initializing the new context. (In this case, I do not care about other architectures.) This problem disappears with gdb 7.1; presumably gdb 7.1 is capable of detecting end of stack through some other means, such as debuginfo.
If GDB is using frame pointers to unwind the stack (pre-DWARF2 method) it stops when it gets to a null frame pointer, I believe. With DWARF2 things are much more complicated since the "frame pointer" is implicitly determined by the stack pointer combined with the insruction pointer and DWARF2 frame offset information for the current instruction, but essentially the effect is the same. Not sure which FreeBSD uses these days.
taskstart
, the framepointer is saved on entry. I added code to set ebp of the created context to zero and gdb 6.1.1's stack traces look correct. Thanks again - Conrad Meyer 2012-04-05 18:11
The gdb
documentation says that one way it stops listing backtrace frames is after the return address for main()
.
See ftp://sourceware.org/pub/gdb/snapshots/current/gdb-7.4.50.20120405.tar.bz2 in gdb/doc/gdb.textinfo at @cindex backtrace beyond @code{main} function
line 6251.
main
- Conrad Meyer 2012-04-05 20:54
taskstart
something like main()
, _main()
, or __main()
- wallyk 2012-04-05 20:58
taskstart
. The libtask schedular swaps userspace contexts into the context which begins at taskstart
. I guess taskstart
could be renamed to main
or _main
or whatever, but that seems like a huge kludge. Initializing the frame pointer to zero seems sufficient for gdb6 to detect the end of the stack, and will work regardless of the name of the initial function in the context - Conrad Meyer 2012-04-05 21:06