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.

• c
• gdb

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.

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.