From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23303 invoked by alias); 6 Nov 2014 17:55:18 -0000 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 Received: (qmail 23287 invoked by uid 89); 6 Nov 2014 17:55:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: e33.co.us.ibm.com Received: from e33.co.us.ibm.com (HELO e33.co.us.ibm.com) (32.97.110.151) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 06 Nov 2014 17:55:16 +0000 Received: from /spool/local by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 6 Nov 2014 10:55:14 -0700 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e33.co.us.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 6 Nov 2014 10:55:12 -0700 Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id C0B67C40003; Thu, 6 Nov 2014 10:43:56 -0700 (MST) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sA6FoiCn56426578; Thu, 6 Nov 2014 16:50:44 +0100 Received: from d03av02.boulder.ibm.com (localhost [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id sA6HtBYY025329; Thu, 6 Nov 2014 10:55:11 -0700 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id sA6Ht8sh025070; Thu, 6 Nov 2014 10:55:08 -0700 Message-Id: <201411061755.sA6Ht8sh025070@d03av02.boulder.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 06 Nov 2014 18:55:07 +0100 Subject: Re: [RFC] PR gdb/17445 fix To: pierre.muller@ics-cnrs.unistra.fr (Pierre Muller) Date: Thu, 06 Nov 2014 17:55:00 -0000 From: "Ulrich Weigand" Cc: binutils@sourceware.org, gdb-patches@sourceware.org In-Reply-To: <005301cfdd4b$aefd3830$0cf7a890$@muller@ics-cnrs.unistra.fr> from "Pierre Muller" at Oct 01, 2014 09:45:32 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14110617-0009-0000-0000-00000622CA79 X-SW-Source: 2014-11/txt/msg00119.txt.bz2 Pierre Muller wrote: > * gdb/dwarf2-frame.c (dwarf2_frame_cache): Avoid double handling of > return address column. Commenting just on the GDB part, this seems incorrect: > /* Use the GDB register number as the destination index. */ > int regnum = gdbarch_dwarf2_reg_to_regnum (gdbarch, column); > > + /* Do not handle return address here, it is done in the next > + loop. This also avoids problem with pei-x86-64 target > + having retaddr_column set to 32 (which is xmm15). */ > + if (column == fs->retaddr_column) > + continue; > /* If there's no corresponding GDB register, ignore it. */ > if (regnum < 0 || regnum >= num_regs) > continue; The "next loop" does not handle the return address. It handles *other* registers that *refer* to the return address. Usually, you have a "return address column" in DWARF, which may or may not itself refer to a register of the platform, and then you have some other rule (either explicit or implicitly defined by the ABI) where the PC refers to the return address column. Conceptually, unwinding is performed in two parts: first, the return address is computed following the instructions for the return address column, and then the PC is set to the unwound return address value (or some value derived from it). On some platforms, the return address itself does not correspond to any register, and is *only* used for setting the PC. On some other platforms, the return address itself corresponds to an actual hardware register, and the unwind instructions for the return address column are in fact also used to determine the unwound value of that register. The latter is the case e.g. on s390, where %r14 is used as return address column. The unwind instructions for %r14 are used both to unwind the actual value of %r14, and to unwind the value of the PC. Your patch would break that usage since you now no longer apply the contents of the return address column to unwind register %r14 on s390. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com