From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17287 invoked by alias); 27 Nov 2012 18:43:52 -0000 Received: (qmail 17275 invoked by uid 22791); 27 Nov 2012 18:43:50 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,MSGID_FROM_MTA_HEADER,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from e06smtp13.uk.ibm.com (HELO e06smtp13.uk.ibm.com) (195.75.94.109) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Nov 2012 18:43:46 +0000 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 27 Nov 2012 18:43:45 -0000 Received: from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 27 Nov 2012 18:43:43 -0000 Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps4074.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qARIhZKH66257068; Tue, 27 Nov 2012 18:43:35 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qARIhgGx022755; Tue, 27 Nov 2012 11:43:42 -0700 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id qARIhelr022639; Tue, 27 Nov 2012 11:43:40 -0700 Message-Id: <201211271843.qARIhelr022639@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 27 Nov 2012 19:43:40 +0100 Subject: Re: [RFC] Wrong register numbers in .dwarf_frame on Linux/PowerPC To: mark.kettenis@xs4all.nl (Mark Kettenis) Date: Tue, 27 Nov 2012 18:43:00 -0000 From: "Ulrich Weigand" Cc: dje.gcc@gmail.com, geoffk@geoffk.org, jakub@redhat.com, gcc-patches@gcc.gnu.org, binutils@sourceware.org, gdb-patches@sourceware.org In-Reply-To: <201211262014.qAQKELci009794@glazunov.sibelius.xs4all.nl> from "Mark Kettenis" at Nov 26, 2012 09:14:21 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 12112718-2966-0000-0000-000006009232 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-11/txt/msg00769.txt.bz2 Mark Kettenis wrote: > > Date: Mon, 26 Nov 2012 20:10:06 +0100 (CET) > > From: "Ulrich Weigand" > > > > Hello, > > > > I noticed what appears to be a long-standing bug in generating .dwarf_frame > > sections with GCC on Linux on PowerPC. > > > > ... > > > > So I'm wondering where to go from here. I guess we could: > > > > 1. Bring GCC (and gas) behaviour in compliance with the documented ABI > > by removing the #undef DBX_REGISTER_NUMBER and changing gas's > > md_reg_eh_frame_to_debug_frame to the original implementation from > > Jakub's patch. That would make GDB work well on new files, but > > there are a large number of binaries out there where we continue > > to have the same behaviour as today ... > > > > 2. Leave GCC and gas as-is and modify GDB to expect GCC numbering in > > .dwarf_frame, except for the condition code register. This would > > break debugging of files built with GCC 4.0 and 4.1 unless we > > want to add a special hack for that. > > > > 3. Like 2., but remove the condition code hack: simply use identical > > numbers in .eh_frame and .dwarf_frame. This would make PowerPC > > like other Linux platforms in that respect. > > > > Thoughts? > > What do other compilers (in particular XLC) do? From a GDB standpoint > it would be a major PITA if different compilers would use different > encodings for .dwarf_frame. In my tests XLC (version 12.1 on Linux) seems to consistently use the GCC register numbering in both .eh_frame and .dwarf_frame. LLVM also consistently uses the GCC register numbering. Looks like this would be another argument for variant 3 ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com