I am useing version 4.18 of gdb on a linux system to debug linux system
kernels over an rs232 line.
The target machine has a variant of the i386_stub.c compiled into the
kernel.
Attempts to:
gdb> p foo(10)
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 notice there is some provision in gdb for an off stack call area for
some enviornments.
Has anyone done any work on this problem?
George
PS. I am willing to do some or all of the work to fix this problem if I
can get some pointers from the maintainers.
GA
