From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12162 invoked by alias); 26 Jan 2006 23:27:38 -0000 Received: (qmail 12153 invoked by uid 22791); 26 Jan 2006 23:27:37 -0000 X-Spam-Check-By: sourceware.org Received: from mail.emacinc.com (HELO mail.emacinc.com) (208.248.202.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Jan 2006 23:27:35 +0000 Received: from emac77.emacinc.com ([208.248.202.77] helo=eng011.emacinc.com) by mail.emacinc.com with esmtp (Exim 4.50) id 1F2GWJ-00086G-Kq; Thu, 26 Jan 2006 17:27:20 -0600 From: NZG To: gdb-patches@sourceware.org Date: Thu, 26 Jan 2006 23:27:00 -0000 User-Agent: KMail/1.8.2 Cc: Daniel Jacobowitz , Mark Kettenis References: <200601231438.26040.ngustavson@emacinc.com> <200601262240.k0QMe7SC026344@elgar.sibelius.xs4all.nl> <20060126224429.GA20076@nevyn.them.org> In-Reply-To: <20060126224429.GA20076@nevyn.them.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200601261726.11037.ngustavson@emacinc.com> X-SA-Exim-Connect-IP: 208.248.202.77 X-SA-Exim-Mail-From: ngustavson@emacinc.com Subject: remote connection crash, was frame theory Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Relay: X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00437.txt.bz2 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.