From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5660 invoked by alias); 25 Sep 2003 02:02:30 -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 5651 invoked from network); 25 Sep 2003 02:02:28 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 25 Sep 2003 02:02:28 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 849592B89 for ; Wed, 24 Sep 2003 22:02:22 -0400 (EDT) Message-ID: <3F724CAE.3040502@redhat.com> Date: Thu, 25 Sep 2003 02:02:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: GDB without traditional frames Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00312.txt.bz2 Hello, As an accademic exercise I decided to see what would happen if a PPC64 GDB was configured to only use dwarf2 cfi (just disable the trad-frame code). The short answer is "it works (mostly)". The long answer is ... It relies on there being 100% coverage of the CFI. System libraries can sometimes be lacking. Assembler stubs, for instance, will trip things up. Irony here is that it's those same assembler routines that trip up traditional unwinders. Anyway, an unwinder capable of unwinding just LR works pretty well. GCC CFI leaves registers as "unspecified" and the "assume same value" hack isn't sufficient. For PPC64, GCC points the "return_column" at dwarf2 num 65 (that's the FPSCR but lets ignore that m'key :-). It needs to specify that by default the "return_column" has the same value as the "LR" column. So while trad unwind code is useful, I think it can now be considered largely optional. I've got more GCC bugs to file :-) enjoy, Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9597 invoked by alias); 25 Sep 2003 14:30:11 -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 9510 invoked from network); 25 Sep 2003 14:30:08 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 25 Sep 2003 14:30:08 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 849592B89 for ; Wed, 24 Sep 2003 22:02:22 -0400 (EDT) Message-ID: <3F724CAE.3040502@redhat.com> Date: Thu, 25 Sep 2003 14:45:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: GDB without traditional frames Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00315.txt.bz2 Message-ID: <20030925144500.2lC5Ea3mQQdiSYC21JGF9JMkPTAMNmOl0mKArl5iRcs@z> Hello, As an accademic exercise I decided to see what would happen if a PPC64 GDB was configured to only use dwarf2 cfi (just disable the trad-frame code). The short answer is "it works (mostly)". The long answer is ... It relies on there being 100% coverage of the CFI. System libraries can sometimes be lacking. Assembler stubs, for instance, will trip things up. Irony here is that it's those same assembler routines that trip up traditional unwinders. Anyway, an unwinder capable of unwinding just LR works pretty well. GCC CFI leaves registers as "unspecified" and the "assume same value" hack isn't sufficient. For PPC64, GCC points the "return_column" at dwarf2 num 65 (that's the FPSCR but lets ignore that m'key :-). It needs to specify that by default the "return_column" has the same value as the "LR" column. So while trad unwind code is useful, I think it can now be considered largely optional. I've got more GCC bugs to file :-) enjoy, Andrew