Re: Examining copied stack contents

["Petr Hluzín" <petr.hluzin@gmail.com>]

Hello Martin and list

On 3 July 2010 12:46, Martin Schröder <gschroeder@onlinehome.de> wrote:
> Hello everyone.
>
> I'm currently implementing a high-level debugger based on GDB for a
> coroutine-based simulation framework. The platform is GNU/Linux on x86.
>
> 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. It's this latter aspect that gives
> me terrible headaches in GDB.
>
> My question is simply: Is it possible to point GDB to the copied contents of
> the call stack and tell it to print out the information contained therein?

(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.

> 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.)

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

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

-- 
Petr Hluzin