From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24243 invoked by alias); 16 Dec 2002 17:54:05 -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 24125 invoked from network); 16 Dec 2002 17:54:01 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 16 Dec 2002 17:54:01 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7A0A53CBB; Mon, 16 Dec 2002 12:53:59 -0500 (EST) Message-ID: <3DFE1337.5000702@redhat.com> Date: Mon, 16 Dec 2002 09:57: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: Michal Ludvig Cc: GDB Patches Subject: Re: [RFA] Artifical dwarf2 debug info References: <3DFBD14C.7090501@suse.cz> <3DFE0741.7020902@redhat.com> <3DFE1003.8030004@suse.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00484.txt.bz2 > Andrew Cagney wrote: > If I understand this correctly, you've created create dwarf2cfi info for a function that has no such info. That way the dwarf2cfi code can unwind a function that doesn't actually have CFI? > > Yes. > >> 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). > > I think cfi_frame_chain() does what you expect from cfi-frame unwinding function. However it is useless if you have no CFI info ;-) And that's the goal of my patch - provide a CFI when there are none and continue as if it was there for ages. cfi_frame_chain() is currently being replaced by frame->id_unwind(). > For your problem, wouldn't it be better to, instead of creating fake CFI info, implement custom frame unwind functions that handle your case? > > There is a lot of different cases (functions with and without prologue, functions allocating some space on the stack, signal trampolines, etc.), and each one of would need to have a special handler. My approach seems to be more general to me (only one more function per architecture and several sets of data). And no, it wouldn't be better to do it a different way, because this way it's already written and verified that it works ;-) Andrew