From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31616 invoked by alias); 16 Dec 2002 18:01:03 -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 31427 invoked from network); 16 Dec 2002 18:00:59 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 16 Dec 2002 18:00:59 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 893693CBC; Mon, 16 Dec 2002 13:00:57 -0500 (EST) Message-ID: <3DFE14D9.7040102@redhat.com> Date: Mon, 16 Dec 2002 10:04: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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00486.txt.bz2 > That's right. > > >> If that is the case then I don't think this is either necessary or >> correct. A `struct frame_info' allows frame specific unwind functions - >> at present only dummy-frame and saved-regs-frame versions are >> implemented, however the next ones to implement are cfi-frame (unwind >> using CFI info) and regs-frame (unwind using the register cache). >> >> For your problem, wouldn't it be better to, instead of creating fake CFI >> info, implement custom frame unwind functions that handle your case? > > > Hrm. What do you mean by regs-frame? If it's for the current frame > wouldn't that be a frame which just doesn't unwind? A frame that gets the saved registers from the register cache. As for uses: - an inner-most frame that for some reason doesn't unwind (i.e., create_new_frame() barfs). - the frame that is inner to `current frame'. > As for this situation, and the similar one for i386... there are three > unwind functions, to find the previous frame's registers, ID, and PC. > For this case we just want to express a normal function call which > saves no registers; pretty easy. But for i386 I'll want to express > something which initially pushes a register, and then does some work, > pops it, and does more work before returning. So you're proposing that the saved-regs code be used to generate a cfi description as well? Interesting. Andrew > There's plenty of ways to express that but it seems to me that the most > useful one would be to have essentially a glorified prologue reader > which builds that description. Then the machinery to handle that > description is - you guessed it - a standard CFI reader. It might be > nice to someday split up the CFI parser and executer so that we could > provide the description less obtusely, but I'd hate to see us duplicate > the machinery. > BTW, > /* See description above. The previous frame's resume address. > Save the previous PC in a local cache. */ > frame_pc_unwind_ftype *pc_unwind; > > /* See description above. The previous frame's resume address. > Save the previous PC in a local cache. */ > frame_id_unwind_ftype *id_unwind; > > Second comment is a past-o? Thanks. Andrew