From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13745 invoked by alias); 16 Dec 2002 19:25:20 -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 13737 invoked from network); 16 Dec 2002 19:25:18 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 16 Dec 2002 19:25:18 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 0A26B3CBB; Mon, 16 Dec 2002 14:25:16 -0500 (EST) Message-ID: <3DFE289B.3080904@redhat.com> Date: Mon, 16 Dec 2002 11:34:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.1) Gecko/20021211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Michal Ludvig , GDB Patches Subject: Re: [RFA] Artifical dwarf2 debug info References: <3DFBD14C.7090501@suse.cz> <3DFE0741.7020902@redhat.com> <20021216172813.GA18150@nevyn.them.org> <3DFE14D9.7040102@redhat.com> <20021216181104.GA21047@nevyn.them.org> <3DFE1ECD.5080908@redhat.com> <20021216185750.GA24656@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00499.txt.bz2 >> >> Need to figure out how/were this should tie into the rest of the frame >> structure. The CFI code is not exactly integrated into the mainstream. >> >> Here, the key function is get_prev_frame() where GDB first unwinds the >> PC and then uses that to determine what is needed to unwind/create the >> rest of the frame. It could easily read: >> >> if (pc in dummy-frame) >> create dummy frame; >> else if (pc in cfi frame) >> create cfi frame; >> else if (pc in something else) >> create some other frame; >> >> or even: >> >> while (frame in known unwind types) >> if (frame and pc match) >> return create that frame; >> >> that is, a target will support a number of frame types, each identified >> using the PC. > > > If I'm scanning this code correctly, all we would need to do would be > to connect set_unwind_by_pc to the CFI machinery. No, it's more > complicated than that, we still call both FRAME_CHAIN and frame_pc_unwind; > I'm not entirely clear on how frame_saved_regs_id_unwind works. > Similarly in get_prev_frame. FRAME_CHAIN is going away. The steps are broadly: pc = pc-unwind (next_frame) if (not an edge case like dummy frame where the id doesn't need to be unwound because the frame can be identified using the callee's ID) id = id-unwind (next_frame); create frame from pc/id setting new unwind methods using pc. (frame_saved_regs_id_unwind is there to keep code that just implements frame chain working.). > But what I'd like to see is something like you've sketched above. > Probably check first for dummy frame, then for sigtramp frame, then for > CFI frame, and then fall back to the defaults. Yes. Should the choices/order be hardwired or specified by the architecture though? I.e., iterate over a list of possible frames that are specified by the architecture. The catch is that it needs to unwind the PC before anything else. That way it can correctly set the type. Like I said, patch for that pending. Andrew