How does GDB determine the bottom of the stack?

Go To StackoverFlow.com

5

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.

2012-04-05 15:30
by Conrad Meyer
this sounds like a question to ask on the gdb developers mailing list - MK. 2012-04-05 15:38


2

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.

2012-04-05 16:32
by R..
This is fairly ancient FreeBSD (~7.2, I believe). Thanks - Conrad Meyer 2012-04-05 17:26
Looking at a disassembly of 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


0

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.

2012-04-05 19:05
by wallyk
Sure, but this isn't especially helpful in my situation because none of these contexts begin at main - Conrad Meyer 2012-04-05 20:54
@ConradMeyer: How about naming the function which calls taskstart something like main(), _main(), or __main() - wallyk 2012-04-05 20:58
Nothing calls 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
Ads