From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30071 invoked by alias); 12 Oct 2006 05:39:59 -0000 Received: (qmail 30057 invoked by uid 22791); 12 Oct 2006 05:39:58 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 12 Oct 2006 05:39:48 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 796C548CC13; Thu, 12 Oct 2006 01:39:46 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16771-01-4; Thu, 12 Oct 2006 01:39:46 -0400 (EDT) Received: from takamaka.act-europe.fr (unknown [70.71.0.212]) by nile.gnat.com (Postfix) with ESMTP id 320C948CBE6; Thu, 12 Oct 2006 01:39:46 -0400 (EDT) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id DB54E47F00; Wed, 11 Oct 2006 22:39:44 -0700 (PDT) Date: Thu, 12 Oct 2006 05:39:00 -0000 From: Joel Brobecker To: ligang@sunnorth.com.cn Cc: gdb@sourceware.org, bjgnu@sunnorth.com.cn Subject: Re: fail to get ra and bp Message-ID: <20061012053944.GN1065@adacore.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00071.txt.bz2 > I am porting GDB to a new target. Would you mind telling us what this new target is? I believe this will greatly help us provide more accurate answers. In the meantime... > The prologue has two insns ---- push ra and push bp. > When back tracing and printing variables, gdb will look for return address > of this frame and frame pointer on stack. > Unfortunately, If compiling with -O2, the two insns are probably deleted. > So, GDB will not get ra and bp value. Typical problem. My recommendation, stay away from prologue analysis as much as you can, because as you know, higher levels of optimization will break the typical frame layout. What you want, is have this information provided by the compiler itself and dumped into the objects in some form. One very popular form, at least in the GNU world, is DWARF CFI. There is also another popular form, which I don't really know much about. The information is stored in .eh_frame sections. But it essentially does the same: It tells you how to unwind the call stack. This is what you want because this information allows you to avoid tricky prologue scanning and hairy heuristics to try to guess where things are. Now that I think of it, if you have no choice but do prologue scanning, you might want to look at a framework that was recently contributed which should make your task easier. I think it's prologue-value.[hc]. -- Joel