From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14672 invoked by alias); 28 Feb 2003 15:48:54 -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 14212 invoked from network); 28 Feb 2003 15:48:43 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 28 Feb 2003 15:48:43 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 2BBDD2A9C; Fri, 28 Feb 2003 10:50:49 -0500 (EST) Message-ID: <3E5F8559.1020708@redhat.com> Date: Fri, 28 Feb 2003 15:48:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michal Ludvig 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> <3E5F5DEE.3030505@suse.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00812.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? Well, to fix this specific bug I think you'd just need to implement: save_dummy_frame_tos() unwind_dummy_id() (see uncommitted patch I posted). And ensure that the top-of-stack value saved by save_dummy_frame_tos() matches the id.base value returned by unwind_dummy_id(). -- The cleanup is more substantial:. The first shaky step is to implement a cfi-frame.[hc] object (using dwarf2expr.[hc]?). After that are the separate x86-64 specific unwinders: traditional, sigtramp. The key difference is that with the old code the sequence: frame->get_saved_register () ->x86_64_get_saved_register () ->cfi_get_saved_register () where as the new code is more direct: frame->register_unwind() ->cfi_register_unwind() (the x86-64 code doesn't get a look in), and very recursive: frame->register_unwind() ->cfi_register_unwind(frame) ... determines that it needs the next frame's register ... that frame happens to be a dummy frame->register () frame->next->register_unwind() ->dummy_frame_register_unwind(frame->next) Andrew