This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
remote connection crash, was frame theory
On Thursday 26 January 2006 4:44 pm, Daniel Jacobowitz wrote:
> On Thu, Jan 26, 2006 at 11:40:07PM +0100, Mark Kettenis wrote:
> > To me, it looks like you're connecting to a buggy stub.
>
> He's connecting to basically a standard gdbserver, poised at
> the first instruction of the program. Memory has garbage
> and/or is invalid - no MMU so reading from garbage memory
> is a bit more serious than is typical for GDB.
righto, it crashes the remote kernel and sends my host into an infinite loop
in gdb.
> The best thing here would be, if the stub can find out from
> the kernel what constitutes "valid" RAM, to refuse reads to
> it. Then ignore the ugliness when you type backtrace and
> don't have a stack yet - it's not real surprising that doesn't
> work!
It needs to do something predictable that doesn't destroy the system, that's
my only criteria.
Understand that It's not just for my personal vanity that this needs to work.
I am trying to be compatible with the standard Eclipse CDT.
On of the first things the Eclipse CDT does upon connecting to a gdbserver is
to use gdb's MI interface to pull down all the current frames. (which has the
same effect as backtrace since it parses through the linked list of frames)
This can't be that outlandish a thing to do, because it works just fine on x86
systems.
Yes, I could modify the Eclipse CDT not to do this, but I think the proper
thing to fix is gdb, since it's desired behavior cannot possibly be a kernel
oops.
Stepping through the code I can see that remote_fetch_registers is never
called before this crash happens, all the data being used in the backtrace
appears to be transferred in the initial connection and cached.
It's this cached data that doesn't create a valid enviornment for a backtrace.
If I can learn a little more about it I may wind up altering the gdbserver
program to connect differently, or modifying gdb to parse it differently,
whatever makes more sense.
In any case, since this error occurs based on data transferred solely on the
special case of the initial connection, I suspect it is fixable.
NZG.