From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14979 invoked by alias); 7 Mar 2003 15:48:15 -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 14971 invoked from network); 7 Mar 2003 15:48:13 -0000 Received: from unknown (HELO kerberos.suse.cz) (195.47.106.10) by 172.16.49.205 with SMTP; 7 Mar 2003 15:48:13 -0000 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (SuSE SMTP server) with ESMTP id E576559D362; Fri, 7 Mar 2003 16:48:12 +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 h27FmC405875; Fri, 7 Mar 2003 16:48:12 +0100 X-Authentication-Warning: chimera.suse.cz: Host naga.suse.cz [10.20.1.16] claimed to be suse.cz Message-ID: <3E68BF3C.2090503@suse.cz> Date: Fri, 07 Mar 2003 15:48: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] Debug info detection. References: <3E67D471.3040100@suse.cz> <3E68B9FE.6090207@redhat.com> In-Reply-To: <3E68B9FE.6090207@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00160.txt.bz2 Andrew Cagney wrote: >> Hi all, >> The attached patch adds new function cfi_have_unwind_info() that I'll >> use for detection, whether a given function has a dwarf2 unwind info >> (from .eh_frame or .debug_frame) or not. I'll use it in the upcomming >> x86_64_frame_p() to detect which set of unwind functions should be >> returned for a given frame. > > Your comment about x86_64_frame_p() makes me wonder if you're going in > the right direction. > > Looking at the d10v, you'll see: > > frame_unwind_append_predicate (gdbarch, d10v_frame_p); > > For the x86-64, since it wants to also use dwarf2cfi and dwarf2eh, I'd > expect to see something like: > > /* Try for a true CFI frame first. If that fails, fall back to > a .eh_frame info. */ > frame_unwind_append_predicate (gdbarch, dwarf2cfi_frame_p); > frame_unwind_append_predicate (gdbarch, dwarf2eh_frame_p); > > /* Finally, and as a last resort, use a prologue based unwinder. */ > frame_unwind_append_predicate (gdbarch, x86_64_frame_p); For now I have... const struct frame_unwind * x86_64_frame_p (CORE_ADDR pc) { struct frame_unwind *unwind_cfi = NULL; struct frame_unwind *unwind_asm = &x86_64_asm_frame_unwind; struct frame_unwind *unwind_sigtramp = &x86_64_sigtramp_frame_unwind; char *name; find_pc_partial_function (pc, &name, NULL, NULL); if (gdbarch_pc_in_sigtramp (current_gdbarch, pc, name)) return unwind_sigtramp; else if (cfi_have_unwind_info (pc)) return unwind_cfi; /* Returns NULL here... */ else return unwind_asm; } I.e. I'll handle sigtramps and non-CFI functions via the new way and fall back to old methods for CFI functions. That's because the CFI unwinder works quite well and I don't need to change it now, but backtrace through sigtramps doesn't work almost at all, and backtrace from non-cfi functions works only with my uncommitted hack. Both of these cases must be solved. > While I'm sure that splitting dwarf2cfi and dwarf2eh is logical, having Why should we have different ways for unwinding with information taken from .debug_frame (is that what dwarf2cfi should be for?) and from .eh_frame (dwarf2eh)? Both of these sections provide the same data and the only different bits are in their parsing... > separate x86_64_frame_p() that only implements traditional prologe based > unwind is correct. > > Can I suggest starting from the other end - a new file > dwarf2cfi-frame.[hc] and then moving in from there? The dwarf2expr.[hc] > code was recently added and that was ment to superseed much of dwarf2cfi.c. As I said higher - I'm doing this to solve backtrace for non-cfi frames. Rewriting the CFI engine is not my priority right now. Michal Ludvig -- * SuSE CR, s.r.o * mludvig@suse.cz * (+420) 296.545.373 * http://www.suse.cz