From patchwork Mon May 27 15:46:22 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Bruel X-Patchwork-Id: 246612 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "www.qmailtoaster.com" (not verified)) by ozlabs.org (Postfix) with ESMTPS id E6ECA2C01FC for ; Tue, 28 May 2013 01:46:56 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; q=dns; s=default; b=DRBMF7smHJ76yCOZA OSW/PqLEZUK66rU4ymQEIrvg4U0BEnk04Sp/ereLk6A01aEm3AgyQwuHYKBN9Ro5 S/obL1E/7SJrqCR5U/RMENQFsoPGM7USo/wEk794bhdpayE/irzd/Xp16AfHj1JZ V35/hfUzTEcFHAFQ7zNT9fBWQM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; s=default; bh=w2oESUHiSBxUgcpZ6qql+Ow jjQo=; b=IlVS4QG49AyLV4v4VJtkHI/nm4Ky2asjSnlgKRXSwKbtOShDYWdpmX2 mRUL2sAFbYqXh7DVhmyC45LCy3hgEsBdkI8J5Q8w1Kv43xLINRYufrPCv1L8dHlJ Y1S7wgA59OEum53PLSYuMbLgBZpjdEVPfrnpYCXrQqC9JQwvO9jM= Received: (qmail 19197 invoked by alias); 27 May 2013 15:46:49 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 19121 invoked by uid 89); 27 May 2013 15:46:41 -0000 X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_DNSWL_MED, RCVD_IN_HOSTKARMA_W, TW_DB, TW_DW, TW_FP, TW_VF autolearn=ham version=3.3.1 X-Spam-User: qpsmtpd, 2 recipients Received: from eu1sys200aog123.obsmtp.com (HELO eu1sys200aog123.obsmtp.com) (207.126.144.155) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 27 May 2013 15:46:37 +0000 Received: from beta.dmz-eu.st.com ([164.129.1.35]) (using TLSv1) by eu1sys200aob123.postini.com ([207.126.147.11]) with SMTP ID DSNKUaN/1izDnKIw+9qwafBg0WKaZXMEPJbG@postini.com; Mon, 27 May 2013 15:46:36 UTC Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 976711EE; Mon, 27 May 2013 15:46:23 +0000 (GMT) Received: from Webmail-eu.st.com (safex1hubcas2.st.com [10.75.90.16]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 5159A566E; Mon, 27 May 2013 15:46:08 +0000 (GMT) Received: from [164.129.122.89] (164.129.122.89) by webmail-eu.st.com (10.75.90.13) with Microsoft SMTP Server (TLS) id 8.3.279.5; Mon, 27 May 2013 17:46:23 +0200 Message-ID: <51A37FCE.7010701@st.com> Date: Mon, 27 May 2013 17:46:22 +0200 From: Christian Bruel User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "gcc-patches@gcc.gnu.org" Cc: Kaz Kojima , Ramana Radhakrishnan , rmansfield at qnx dot com , ktkachov at gcc dot gnu.org , Cary Coutant Subject: Re: [DWARF] Fix multiple register spanning location. References: <5188AFC2.1000105@st.com> In-Reply-To: X-Virus-Found: No On 05/16/2013 12:27 AM, Cary Coutant wrote: >>> How about using dbx_reg_number (XVECEXP (regs, 0, i)) instead? The >>> bare use of DBX_REGISTER_NUMBER earlier in that function is protected >>> by a gcc_assert, but this one isn't. >> For the respective targets maintainers that drop into the thread: Here is a summary of the problem: Since http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00209.html, dwarf double floating point registers are not correctly described for the SH. But this patch was needed to fix an assertion in the dwarf2cfi. Therefore, we have a discrepancy between the different targets, that can result in assertions, (or possibly silent wrong unwind code I believe) SH,MIPS,C6X ; dwarf_register_span returns hard_reg numbers. regno is never translated for DBX ARM NEON ; converts regno into DBX numbers POWERPC ; ? returns boths. So a second set of patches http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01230.html http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00312.html fixed it with a common rule. All interfaces are changed to return hard_reg numbers only. multiple_reg_location is in charge of calling DBX_REGISTER_NUMBER with an assertion check. Well, in fact this was not doing some good for the powerpc, that now asserts here. The problem is that rs6000_dwarf_register_span stores in the PARALLEL rtx both the hard reg and the dbx reg, so we can't call dbx_reg_number in it. Using DBX_REGISTER_NUMBER instead of dbx_reg_number restores the previous working status for all targets. This is dwarf-span-assert-rs6000.patch for reference. However I feel a little bit uncomfortable with this solution that doesn't seem to fix the root cause. The dbx_register_number hooks is called basically from two places : dwarf2cfi.c and dwarf2out.c. That show different uses: either we want to refer to the hard regno when dealing with the cfa description (whereas we want DWARF_FRAME_REGNUM, not DBX_REGISTER_NUMBER). or we use the DBX_REGISTER_NUMBER for output register locations. Since this information cannot be detected contextually, I'd like to extend the dwarf_register_span target hook to return a dbx number or not. This is dwarf-span-target-dbx.patch build tested with the configurations that failed at one time or the other: - sh64-unknown-elf (The original sh64-elf build failure assertion in dwarf2cfi is fixed.) - arm-none-eabi -with-fpu=neon-vfpv4 - powerpc-e500v2-linux-gnuspe - x86_64-unknown-linux-gnu sanity build OK Is dwarf-span-target-dbx.patch OK for trunk ?. More comments ? Many Thanks, Christian 2013-05-23 Christian Bruel PR debug/57389 * dwarf2out.c (multiple_reg_loc_descriptor): Use DBX_REGISTER_NUMBER instead of dbx_reg_number. Index: gcc/dwarf2out.c =================================================================== --- gcc/dwarf2out.c (revision 199354) +++ gcc/dwarf2out.c (working copy) @@ -10660,8 +10660,11 @@ multiple_reg_loc_descriptor (rtx rtl, rtx regs, { dw_loc_descr_ref t; - t = one_reg_loc_descriptor (dbx_reg_number (XVECEXP (regs, 0, i)), + /* Cannot use dbx_reg_number here because regno could be out of the hard-reg + range and not handled by DBX_REGISTER_NUMBER. See rs6000.h. */ + t = one_reg_loc_descriptor (DBX_REGISTER_NUMBER (REGNO (XVECEXP (regs, 0, i))), VAR_INIT_STATUS_INITIALIZED); + add_loc_descr (&loc_result, t); add_loc_descr_op_piece (&loc_result, size); }