From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16921 invoked by alias); 7 Jul 2003 14:46:31 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 16913 invoked from network); 7 Jul 2003 14:46:31 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 7 Jul 2003 14:46:31 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 8FBD12B5F; Mon, 7 Jul 2003 10:46:26 -0400 (EDT) Message-ID: <3F0987C2.4010007@redhat.com> Date: Mon, 07 Jul 2003 14:46:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com, rearnsha@arm.com Subject: Re: [RFA/ARM] Framificate the ARM port [3/3] References: <20030630225509.GA30844@nevyn.them.org> <3F01A9A0.90005@redhat.com> <20030707134715.GA24634@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-07/txt/msg00124.txt.bz2 > Makes sense. I will need to cache a PC to fix some corner cases with > signal trampolines, but I'm not fixing that bug right now. Can you expand? I can understand cacheing the previous frame's PC but not this frame's. >> >+/* Assuming NEXT_FRAME->prev is a dummy, return the frame ID of that >> >+ dummy frame. The frame ID's base needs to match the TOS value >> >+ saved by save_dummy_frame_tos(), and the PC match the dummy frame's >> >+ breakpoint. */ > >> >> ... tos() and returned by arm_push_dummy_call. > > > Copied this comment verbatim from three other implementations. You > might want to update those. Sigh! Code is breeding again ... >> >+/* Given THIS_FRAME, find the frame's resume PC (which will be part of the >> >+ frame ID for THIS_FRAME's caller's frame). */ > >> >> Given THIS_FRAME, find the PREV frame's resume PC (which will be used to >> find the PREV frame's function and that in turn used to construct the >> PREV frame's ID). > > > Eh? Uch, I suppose. "resume PC" is a bit ambiguous. > > The reason that I like my notation better is that I don't need to think > about what "this frame's caller" means. But every time I see NEXT or > PREV I have to take five seconds to work it out. Caller is > unambiguous. Don't forget that in the case of signal trampolines and sentinel frames there is no caller. Older and younger work better but prev and next are what the dwarf2 spec and before that gdb, long ago, decided to use :-/ Andrew