From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15009 invoked by alias); 16 Dec 2002 17:40:22 -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 14955 invoked from network); 16 Dec 2002 17:40:21 -0000 Received: from unknown (HELO kerberos.suse.cz) (195.47.106.10) by sources.redhat.com with SMTP; 16 Dec 2002 17:40:21 -0000 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (SuSE SMTP server) with ESMTP id 30C5959D361; Mon, 16 Dec 2002 18:40:20 +0100 (CET) Received: from suse.cz (naga.suse.cz [10.20.1.16]) by chimera.suse.cz (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id gBGHeKX11520; Mon, 16 Dec 2002 18:40:20 +0100 X-Authentication-Warning: chimera.suse.cz: Host naga.suse.cz [10.20.1.16] claimed to be suse.cz Message-ID: <3DFE1003.8030004@suse.cz> Date: Mon, 16 Dec 2002 09:46:00 -0000 From: Michal Ludvig Organization: SuSE CR User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: cs, cz, en MIME-Version: 1.0 To: Andrew Cagney Cc: GDB Patches Subject: Re: [RFA] Artifical dwarf2 debug info References: <3DFBD14C.7090501@suse.cz> <3DFE0741.7020902@redhat.com> In-Reply-To: <3DFE0741.7020902@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00482.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. > 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 ;-) Michal Ludvig -- * SuSE CR, s.r.o * mludvig@suse.cz * (+420) 296.545.373 * http://www.suse.cz