"J.T. Conklin" wrote:
>
> [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 current stub is called by the linux kernel on a trap AFTER it pushes
all the registers and such and then does other checking. Are you
suggesting that we not access the stub this way or that the stub move
the stack contents after it is entered? Note that one test that is done
is to see if the trap is for a user program or if it is the kernel that
is being debugged.
>
> The i386 and m68k example stubs (i386-stub.c, m68k-stub.c) distributed
> with GDB set up such a stack
>
They appear to work on the assumption that they can grab the traps from
the top. Great if we don't have an OS also trying to use them.
George
