remote connection crash, was frame theory

[NZG <ngustavson@emacinc.com>]

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.