[EMAIL PROTECTED] (George Anzinger) writes:
> Fail with a complete melt down of the target system. Examination of the
> remote traffic seems to indicate that the call to foo() is being built
> on the stack of the target. The problem is that the stack address
> provided by the stub is the stack address at the time of the
> breakpoint. The systems call to the stub and the stubs own internal
> calls are on this stack in the area used by the call to foo().
>
> So:
>
> It seems to me that this is a problem that needs help both in the stub
> (possibly in a lot of stubs) and in gdb. I think the solution is to
> have the stub provide a memory area for the call and a new stub command
> to make the call. This way the calls stack will properly unwind back to
> the stub should the call itself run into a break point.
I don't think that any changes are needed to GDB. If the stub sets up
itself a separate debug/exception stack, everything should work OK. I
had the same problem in our powerpc stub, and that's all I needed to do
to fix it.
The i386 and m68k example stubs (i386-stub.c, m68k-stub.c) distributed
with GDB set up such a stack
--jtc
--
J.T. Conklin
RedBack Networks
