From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18263 invoked by alias); 28 Feb 2003 13:02:42 -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 18190 invoked from network); 28 Feb 2003 13:02:39 -0000 Received: from unknown (HELO kerberos.suse.cz) (195.47.106.10) by 172.16.49.205 with SMTP; 28 Feb 2003 13:02:39 -0000 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (SuSE SMTP server) with ESMTP id B001859D370; Fri, 28 Feb 2003 14:02:38 +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 h1SD2c403312; Fri, 28 Feb 2003 14:02:38 +0100 X-Authentication-Warning: chimera.suse.cz: Host naga.suse.cz [10.20.1.16] claimed to be suse.cz Message-ID: <3E5F5DEE.3030505@suse.cz> Date: Fri, 28 Feb 2003 13:02: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: [patch/rfc] Add a sentinel frame References: <3E305670.3020700@redhat.com> <3E48378E.6090007@suse.cz> <3E492953.8010001@redhat.com> <3E52173B.1030800@suse.cz> <3E538770.6070209@redhat.com> <3E5B98D8.3030002@suse.cz> <3E5BAB7D.8090801@redhat.com> <3E5BD957.9010605@suse.cz> <3E5BDCBD.2030205@redhat.com> <3E5C7512.2080207@suse.cz> <3E5E58FC.3080704@redhat.com> In-Reply-To: <3E5E58FC.3080704@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00806.txt.bz2 Andrew Cagney wrote: > To give this x86-64 thread clear closure. The internal-error you are > seeing from the new frame code is now, officially, "not-a-frame-bug". Yes, I've already realised so. Thank you for confirmation. > The underlying problem is caused by a design flaw (one of many) in the > original CFI code (on which the x86-64 depends). It's trying to use the > CFI unwinder on a block of code that either: has no CFI information; or > has CFI information that isn't relevant to the stack frame being > unwound. Using CFI to unwind such a frame is meaningless. [...] > To fix this problem, the x86-64 will need to implement both that and the > save_dummy_frame_tos() method. OK. So, first I need to convert x86-64 target to use all the new frame-id stuff I think. And then implement handling of different frame types (normal (CFI), dummy, sigtramp, and specifically for x86-64 also normal frames without CFI debug info). Basically all calls to cfi_*() functions from x86-64-*.c files should become x86_64_*() functions that call the appropriate cfi_*() functions if needed, or a frame-type specific thing otherwise. Correct? Michal Ludvig -- * SuSE CR, s.r.o * mludvig@suse.cz * (+420) 296.545.373 * http://www.suse.cz