From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26559 invoked by alias); 16 Dec 2002 17:03:07 -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 26550 invoked from network); 16 Dec 2002 17:03:04 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 16 Dec 2002 17:03:04 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 9E04E3CBB; Mon, 16 Dec 2002 12:02:57 -0500 (EST) Message-ID: <3DFE0741.7020902@redhat.com> Date: Mon, 16 Dec 2002 09:25: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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00479.txt.bz2 > Hi all, > this long patch provides a fix for a very annoying fact, that GDB on x86-64 can't do backtraces from hand-optimized assembler functions (that applies for example to glibc's memset, str*, etc as well as to syscall wrappers). > This is caused by the lack of a valid debug_frame/eh_frame FDE entry for such a function (noone really writes .debug_frame section in his assembler code :-) > > My approach to fix this behaviour is based on the fortunate fact, that most of those affected glibc's functions don't touch the stack at all, so creating an artifical FDE for them is easy. 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? 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? Andrew