This is the mail archive of the
mailing list for the GDB project.
Re: Examining copied stack contents
Petr Hluzín wrote:
(Note I am not familiar in x86 stack-walking stuff.)
In general a debugger needs at least a stack pointer and an
instruction pointer to get a backtrace. If the function containing the
IP uses a frame pointer (a debugger should be able to tell you that)
then debugger needs to know the FP. Which register contains the FP
depends on the prologue type chosen by compiler (on x86 it is always
EBP). Command "info frame <address>" may assume IP is pointed to by
SP. So there are at least 2 arguments (FP+SP) to be provided on any
Therefore I suspect "info frame <address>" is not general enough to be
used in your case.
Mhhhm, I also suspected as much, but the docs  only point out four
architectures where more than just the SP is necessary: SPARC (FP + SP),
MIPS & Alpha (PC + SP) and the 29k architecture (Register SP + Memory SP
The docs did not mention x86, which made me abandon that line of
thinking. Anyway, I'll try to play around with the additional parameters
and see if they change anything.
 - http://www.circlemud.org/cdp/gdb/gdb_7.html#SEC43
That framework implements coroutines by using the C/C++
setjmp/longjmp instructions and by copying the call stack that is
used by each coroutine to dynamically allocated memory on the heap.
Beware that a function compiled without -fomit-frame-pointer saves SP
to stack and gdb uses the value to obtain stack-trace (this is not
quite exact). If you copy a stack somewhere and use gdb to walk the
stack there then gdb will try to use SP values pointing to the "old"
(And you cannot resume execution of the stack while in the new
I also assumed that GDB will parse the contents of the stack to get the
proper sequence of frames. But that's why I deliberately chose to break
the simulation when the stack contents were copied but not yet
overwritten. Thus, even *if* the GDB parses the new stack and
subsequently accesses the old areas, everything should still work,
because the old stack's still in place.
It seems to me that the stack walking algorithm notices some kind of
error, but simply fails to relay it to me. After all, no matter WHAT
address I give GDB, it always returns the same, useless data and never
even once throws an error.
But I'm also aware that the GDB *should be* able to do what I want
it to do. For one, the documentation explicitly mentions that the
feature works with programs that utilize multiple stacks.
Furthermore, the GDB is also able to debug Multi-Threaded programs,
which also need to save the call stack to dynamic heap memory.
When doing multithreaded programs gdb gets register values from
pthread library (or linux kernel?) or by remote target command. And
the stack frames stay where they were created - they are not copied.
Yes, but the app still needs to switch from one stack to another during
execution, which is by all means very similar to copying the stack
somewhere else and resuming execution from there (something I don't need
to do; I merely need to examine the copy, not run it).
So, whatevery causes GDB to accept the move to another stack should also
enable it to move to the /same/ stack at another memory location. I
mean, I could easily live with manipulating a few registers and memory
chunks so that the GDB believes that the new stack location is valid.
If only the documentation would include which data stores are read
during stack traversal! Unfortunately, my attempts at digging around in
the source code was equally fruitless in that regard.
But thanks for pointing out that GDB most likely analyzes the register
values to do its job. I'll see if I can manipulate them to get GDB to do
So, my question is: Is it possible to examine the copied stack? And
if yes, what do I need to give to the GDB to allow it?
I do not know. Someone else have to answer that.
Thanks anyway. You've already helped me enough so that I found a few
more approaches to testing GDB's features.