From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4175 invoked by alias); 9 Jun 2004 15:14:04 -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 3971 invoked from network); 9 Jun 2004 15:13:57 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 9 Jun 2004 15:13:57 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i59FDvi7007275 for ; Wed, 9 Jun 2004 11:13:57 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i59FDu007452; Wed, 9 Jun 2004 11:13:56 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C89D32B9D; Wed, 9 Jun 2004 11:13:50 -0400 (EDT) Message-ID: <40C7292E.5040906@gnu.org> Date: Wed, 09 Jun 2004 15:14:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Steven Johnson Cc: Mark Salter , gdb@sources.redhat.com, drow@false.org Subject: Re: GDB and ARM Frame Pointer strangeness References: <40C42C75.5020208@neurizon.net> <40C53F70.8030101@neurizon.net> <20040608042936.GA7514@nevyn.them.org> <40C54834.4080408@neurizon.net> <20040608122635.35BD37907B@deneb.localdomain> <40C65020.7010904@neurizon.net> In-Reply-To: <40C65020.7010904@neurizon.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00067.txt.bz2 > Everything might be ok, if you are using a software interface that you have "burned and learned" to get executing and which has set up your environment for you, but we have the ability to debug right from a hardware reset, the registers are in this state completley random. There is no ABI in use, and it is inapproriate for GDB to "assume" at this stage that it can dereference R11 and that that register contains the frame pointer. There's nothing special about the state of the inferior immediatly after a reset. R11 (just like any other register) could become corrupt at any moment in the program's execution, and equally could always be valid after a reset. Also, there's nothing special about the debugger generating apparently random memory fetches. Such a fetch could equally come from the user (e.g., via a typo), the target must be robust to such accesses (there is the "mem" command to help with this). Andrew