From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16104 invoked by alias); 8 Jun 2004 04:29:51 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 15939 invoked from network); 8 Jun 2004 04:29:37 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 8 Jun 2004 04:29:37 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1BXYEy-00027X-BB; Tue, 08 Jun 2004 00:29:36 -0400 Date: Tue, 08 Jun 2004 04:29:00 -0000 From: Daniel Jacobowitz To: Steven Johnson Cc: gdb@sources.redhat.com Subject: Re: GDB and ARM Frame Pointer strangeness Message-ID: <20040608042936.GA7514@nevyn.them.org> Mail-Followup-To: Steven Johnson , gdb@sources.redhat.com References: <40C42C75.5020208@neurizon.net> <40C53F70.8030101@neurizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C53F70.8030101@neurizon.net> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-06/txt/msg00048.txt.bz2 On Tue, Jun 08, 2004 at 02:24:16PM +1000, Steven Johnson wrote: > This is all well and good, but at the beginning of the world, when the > target is not yet properly initialised, the frame is corrupt. > Dereferencing R11 (on an ARM) and then looking at that Memory is BAD. > R11 at the beginning of the world doesnt contain anything valid. It is the responsibility of the stub to be robust against bad reads, in general. Most stubs manage this without trouble. > This seems to be a worse problem (to me) than the one supposedly solved > by the piece of code here. I would have thought it would only need to > do this if: > 1. The frame was valid. AND > 2. You modify a frame register OR > 3. You modify any memory within the current Frame. GDB has no concept of "valid" in the sense that you're using it. "There is always a frame" - if we're connected to a target that has registers and memory, it has a frame. If your stub is going to fall down like this I recommend having the stub initialize registers to point to memory that won't trap when read. -- Daniel Jacobowitz