From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15845 invoked by alias); 20 May 2009 14:12:59 -0000 Received: (qmail 15835 invoked by uid 22791); 20 May 2009 14:12:58 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,FS_NEW_XXX X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 May 2009 14:12:52 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 2022C2BACA2; Wed, 20 May 2009 10:12:50 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id F1WrbpPftEvT; Wed, 20 May 2009 10:12:50 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id C3A6A2BAC9A; Wed, 20 May 2009 10:12:49 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 242BEF5962; Wed, 20 May 2009 16:12:43 +0200 (CEST) Date: Wed, 20 May 2009 14:12:00 -0000 From: Joel Brobecker To: Florent DEFAY Cc: jeremy.bennett@embecosm.com, Anthony Berent , gdb@sourceware.org Subject: Re: new port Message-ID: <20090520141243.GE17566@adacore.com> References: <8502af3c0905140623nece4f1dv1e03c2c841c59e42@mail.gmail.com> <1242311828.2994.39.camel@thomas> <8502af3c0905200126v68b6d474g9ee399bc163e8b5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8502af3c0905200126v68b6d474g9ee399bc163e8b5@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 2009-05/txt/msg00139.txt.bz2 > I think of a solution for (2): > As I know PC, I can compute how many saved regs pushes > have been already done. Then, > or1k_unwind_sp (gdbarch, next_frame) + NUM_PUSHES * REG_SIZE > gives me the SP when entering the function (falling stack). That should correct, provided that your description of the frame is correct. There's a somewhat similar situation with i386-tdep.c: Normally, the frame pointer holds the frame address, but sometimes functions are "frameless", and so we compute the frame base using the stack pointer (your this_sp) and the frame size. What's also interesting with x86 is that, even when the frame uses a frame pointer, the frame base address is actually an offset from what that register contains (I think the offset is +8. What I'm trying to say is that, in the x86 case, the frame base is never the content of a register, and that's not a necessity. > (1) So I cannot find the base: > trad_frame_set_this_base (info, this_sp); > is not correct (the base is the final value, this_sp is not the final value). This is related to your question above: You need to provide the value of the frame base, which apparently is the value of the SP at the time the function was entered. It doesn't need to be the value of any given register. -- Joel