From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30479 invoked by alias); 9 Apr 2002 19:42:39 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 30382 invoked from network); 9 Apr 2002 19:42:36 -0000 Received: from unknown (HELO dberlin.org) (64.246.6.106) by sources.redhat.com with SMTP; 9 Apr 2002 19:42:36 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by dberlin.org (8.11.6/8.11.6) with ESMTP id g39JgZm14164; Tue, 9 Apr 2002 15:42:35 -0400 Date: Tue, 09 Apr 2002 12:42:00 -0000 From: Daniel Berlin To: Andrew Cagney cc: gdb@sources.redhat.com Subject: Re: think-o: dwarf2 CFA != frame->frame (x86-64) In-Reply-To: <3CB33E54.6050605@cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-04/txt/msg00142.txt.bz2 On Tue, 9 Apr 2002, Andrew Cagney wrote: > > >> Please re-read what I wrote. > > > > > > You said " The problem is that this algorithm assumes that each frame uses > > the same mechanism for locating register values. With > > the introduction of dwarf2cfi, this is no longer > > true. Some frames may use the debug info while others may use the > > old prologue analysis technique. > > " > > > > You are incorrect. > > We're going to have to agree to disagree. > Okeydokey. > > It's an either-or case. Never is their a mixture of methods, unless you do > > something illegal. > > If GDB decides to do what you state, it will be incapable of unwinding > through libraries (where there is no debug info). Libraries have debug info as well. Even those without debug info, can still have dwarf2 frame info. Most do these days. You just don't realize it. The default libc that came with my ppc linux distribution contains unwind info for all routines, fer instance. It's glibc 2.2.4 based, for the curious. I installed this distribution a *while* ago, so it's not a recent happening. All the libraries have unwind info as well. No debug info, just unwind info. > > I think that is a significant feature loss and one I don't consder > acceptable. Who says you have lost a feature? > > I see no reason why GDB shouldn't act ``illegally'' and use the > traditional prolog scanner as a fallback to debug info. Now you've twisted my words. I said it would be illegal to attempt to use .eh_frame under the assumption it contains unwind info for all routines. It might, it might not. I said nothing about prolog scanning, besides that it is unnecessary when the dwarf2 unwind info is present. > > Andrew >