Re: Examining copied stack contents

["Martin Schröder" <gschroeder@onlinehome.de>]

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
> arch.
>
> 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] - 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"
> 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.