From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16144 invoked by alias); 20 May 2010 00:21:59 -0000 Received: (qmail 16132 invoked by uid 22791); 20 May 2010 00:21:58 -0000 X-SWARE-Spam-Status: No, hits=-0.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mail-gw0-f41.google.com (HELO mail-gw0-f41.google.com) (74.125.83.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 20 May 2010 00:21:52 +0000 Received: by gwb20 with SMTP id 20so6229601gwb.0 for ; Wed, 19 May 2010 17:21:50 -0700 (PDT) Received: by 10.101.134.29 with SMTP id l29mr11230492ann.175.1274314910404; Wed, 19 May 2010 17:21:50 -0700 (PDT) Received: from zooty (c-76-109-153-227.hsd1.fl.comcast.net [76.109.153.227]) by mx.google.com with ESMTPS id n18sm5462484anl.12.2010.05.19.17.21.48 (version=SSLv3 cipher=RC4-MD5); Wed, 19 May 2010 17:21:49 -0700 (PDT) Received: from zooty (localhost [127.0.0.1]) (Authenticated sender: tom) by zooty.my.lan (Postfix) with ESMTPA id 64D9439A3FC; Wed, 19 May 2010 20:21:47 -0400 (EDT) Date: Thu, 20 May 2010 00:21:00 -0000 From: Tom Horsley To: Mike Frysinger Cc: gdb@sourceware.org Subject: Re: How does gdb deal with bizarre frame descriptions? Message-ID: <20100519202147.4de59642@zooty> In-Reply-To: <201005191842.00180.vapier@gentoo.org> References: <20100518160554.32fa67fc@tomh.ccur.com> <201005191842.00180.vapier@gentoo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-05/txt/msg00060.txt.bz2 On Wed, 19 May 2010 18:41:59 -0400 Mike Frysinger wrote: > look at the frames sections of the gdb internals manual as it describes the > algorithms gdb uses (or rather, the framework gdb has that each arch/port > extends). > > you can also use 'set debug frame 1' to get more insight on the frame > construction. Thanks for the pointers, but I think I have discovered that the compiler is actually generating correct, but ridiculous frame info. The code really is using ebp as a frame register, but it also has stored a copy of the frame pointer on the stack and described that saved copy in the dwarf instead of just using ebp+offset like all the code it generated actually does. I have no clue why it does that :-).