From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24849 invoked by alias); 26 Jan 2006 23:57:10 -0000 Received: (qmail 24841 invoked by uid 22791); 26 Jan 2006 23:57:09 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.204) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Jan 2006 23:57:08 +0000 Received: by zproxy.gmail.com with SMTP id x3so543774nzd for ; Thu, 26 Jan 2006 15:57:06 -0800 (PST) Received: by 10.36.146.8 with SMTP id t8mr2019762nzd; Thu, 26 Jan 2006 15:57:06 -0800 (PST) Received: by 10.37.2.5 with HTTP; Thu, 26 Jan 2006 15:57:06 -0800 (PST) Message-ID: <8f2776cb0601261557x2edce755sd54dbfe12d658267@mail.gmail.com> Date: Thu, 26 Jan 2006 23:57:00 -0000 From: Jim Blandy To: Jim Blandy , NZG , gdb-patches@sourceware.org, Mark Kettenis Subject: Re: remote connection crash, was frame theory In-Reply-To: <20060126234456.GA21704@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200601231438.26040.ngustavson@emacinc.com> <200601262240.k0QMe7SC026344@elgar.sibelius.xs4all.nl> <20060126224429.GA20076@nevyn.them.org> <200601261726.11037.ngustavson@emacinc.com> <8f2776cb0601261542t6b5f002al343ed6c0d78f840c@mail.gmail.com> <20060126234456.GA21704@nevyn.them.org> 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/msg00444.txt.bz2 On 1/26/06, Daniel Jacobowitz wrote: > On Thu, Jan 26, 2006 at 03:42:02PM -0800, Jim Blandy wrote: > > On 1/26/06, NZG wrote: > > > 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 infini= te 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! > > > > The PC is valid at this point, right? If there were clean Dwarf CFI > > for the entry point, marking it as the oldest frame, would that calm > > GDB down? That could be another approach. > > Yes, that should generally work. For reference, I added Dwarf CFI for the _start function in crt0.s for the m32c libgloss port: http://sourceware.org/cgi-bin/cvsweb.cgi/src/libgloss/m32c/crt0.S?rev=3D1.2= &content-type=3Dtext/x-cvsweb-markup&cvsroot=3Dsrc You'll need to look at the CFI section of the Dwarf spec to adapt this to your processor. (Fortunately, Dwarf CFI is pretty independent of the rest of Dwarf, so don't be discouraged by the overall size of the spec.)