This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 [1] 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 + PC).

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.

[1] -

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" stack memory. (And you cannot resume execution of the stack while in the new memory.)

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 something sensible.

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.

So long, Martin Schröder.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]