From patchwork Tue Sep 4 15:13:28 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "H.J. Lu" X-Patchwork-Id: 965969 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-485099-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="k1zskuVv"; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="PB0GztA4"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 424Vj15gW6z9s3C for ; Wed, 5 Sep 2018 01:13:40 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:from:date:message-id:subject:to:cc:content-type; q=dns; s=default; b=GKWWZ5QddMXfrNBHAQZdWvdxfOMc8sxciG9Rpu0jnQ0 06yLvIq/YtIO/EL8o5d6LHn1nJLB5J97Y5vzoUgafi8GIvme0F7BK15/uulIj03h rDVC/ZzstKto9hrXChAJiFWtLgHWihyp9bWoHgR6CtiEgmtCIPQjjIR1glTu3zko = 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 :mime-version:from:date:message-id:subject:to:cc:content-type; s=default; bh=qQnyjNmMbr9ruhkFlNVfTEfakmU=; b=k1zskuVvQzFOLxXsD P/kjMLkZiXCmzq1kcTFvbkdFIdDn/Nqy7F9+wm7q8iF/X0T7OQhPyQMSwciqDvKq fy57K2j7Nz/61sD2lXyuAf126eb4En/9GgerLLyhzE7xhk6bYIi4zydkN6SWSXGi fD1xwyDbLFce/KKskU7t8z/H4w= Received: (qmail 110105 invoked by alias); 4 Sep 2018 15:13:33 -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 110095 invoked by uid 89); 4 Sep 2018 15:13:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.3 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-oi0-f67.google.com Received: from mail-oi0-f67.google.com (HELO mail-oi0-f67.google.com) (209.85.218.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Sep 2018 15:13:31 +0000 Received: by mail-oi0-f67.google.com with SMTP id k12-v6so7359051oiw.8 for ; Tue, 04 Sep 2018 08:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=u9RH7nGdXuZjfzdWruhB6XO8ndCrF44hiHeBN9amTo0=; b=PB0GztA4d/slne9wlEmyUe0CkerwEOV1JRLh+Gub5vxeXyQsbpmB9PUliIeCk3kYG1 6SmQ1TZrslBb5lSALBKxvV5MJBk3Oo5m1noFVfOO/X/gmV1SpLQ5ESXVPQGv9X3kc23W 17Xq1TTqISdKu6sf7ChPfjHbg827/VsHUgclwawVdI7fk3/z97ui/2RctRGbs77uaD0Y MkrAL5uhXpqDLRUvWAX5wmSsdHwLiS2O/9VH/nZdu7Z7bWafKgywa8MfPNJ+UXOJjeuG OHQ9INk1E0Rwqotx/0w7wS+CdRoz1JVwx0a1loEi2RFGgfDk2yMAv4BVMoGepqc2FARf 8XBA== MIME-Version: 1.0 Received: by 2002:a4a:8ad1:0:0:0:0:0 with HTTP; Tue, 4 Sep 2018 08:13:28 -0700 (PDT) From: "H.J. Lu" Date: Tue, 4 Sep 2018 08:13:28 -0700 Message-ID: Subject: [PATCH] DWARF: Allow hard frame pointer even if frame pointer isn't used To: Michael Matz Cc: Segher Boessenkool , Jason Merrill , GCC Patches , Cary Coutant X-IsSubscribed: yes On Mon, Sep 3, 2018 at 10:01 AM, H.J. Lu wrote: > On Mon, Sep 3, 2018 at 9:44 AM, Michael Matz wrote: >> Hi, >> >> On Mon, 3 Sep 2018, H.J. Lu wrote: >> >>> > So, what's the testcase testing then? Before the patch it doesn't ICE, >>> > after the patch it doesn't ICE. What should I look out for so I can see >>> > that what the testcase is producing without the patch is wrong? >>> >>> Before the patch, debug info is wrong since it uses hard frame pointer >>> which isn't set up for the function. You can do "readelf -w" on .o file to >>> verify the debug info. >> >> Yeah, that's what I thought as well, but it's correct: >> >> % ./gcc/cc1plus -quiet -O2 -g -fno-omit-frame-pointer -fvar-tracking x.cc >> % gcc -c x.s >> % readelf -wfi x.o >> ... >> <1><8a>: Abbrev Number: 9 (DW_TAG_subprogram) >> <8b> DW_AT_specification: <0x3a> >> <8f> DW_AT_decl_line : 6 >> <90> DW_AT_decl_column : 5 >> <91> DW_AT_object_pointer: <0xa7> >> <95> DW_AT_low_pc : 0x0 >> <9d> DW_AT_high_pc : 0x3 >> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) >> DW_AT_GNU_all_call_sites: 1 >> ... >> <2>: Abbrev Number: 11 (DW_TAG_formal_parameter) >> DW_AT_name : d >> <101> DW_AT_decl_file : 1 >> <102> DW_AT_decl_line : 6 >> <103> DW_AT_decl_column : 63 >> <104> DW_AT_type : <0x78> >> <108> DW_AT_location : 2 byte block: 91 8 (DW_OP_fbreg: 8) >> ... >> DW_CFA_def_cfa: r7 (rsp) ofs 8 >> DW_CFA_offset: r16 (rip) at cfa-8 >> DW_CFA_nop >> DW_CFA_nop >> ... >> >> So, argument 'd' is supposed to be at DW_AT_frame_base + 8, which is >> %rsp+8+8, aka %rsp+16, which is correct given that it's the eigth argument >> (including the implicit this parameter). > > Can we use DW_AT_frame_base when the frame pointer isn't available? > If yes, > > gcc_assert ((SUPPORTS_STACK_ALIGNMENT > && (elim == hard_frame_pointer_rtx > || elim == stack_pointer_rtx)) > || elim == (frame_pointer_needed > ? hard_frame_pointer_rtx > : stack_pointer_rtx)); > > should be changed to > > gcc_assert (elim == hard_frame_pointer_rtx > || elim == stack_pointer_rtx); > > This will also fix: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593 > Since hard frame pointer is encoded with DW_OP_fbreg which uses the DW_AT_frame_base attribute, not hard frame pointer directly, we should allow hard frame pointer when generating DWARF info even if frame pointer isn't used. OK for trunk? From 6c16105e88c2635bd58fc904e7d28901a7f198f5 Mon Sep 17 00:00:00 2001 From: "H.J. Lu" Date: Tue, 4 Sep 2018 08:01:33 -0700 Subject: [PATCH] DWARF: Allow hard frame pointer even if frame pointer isn't used r251028 commit cd557ff63f388ad27c376d0a225e74d3594a6f9d Author: hjl Date: Thu Aug 10 15:29:05 2017 +0000 i386: Don't use frame pointer without stack access When there is no stack access, there is no need to use frame pointer even if -fno-omit-frame-pointer is used and caller's frame pointer is unchanged. frame pointer may not be available even if -fno-omit-frame-pointer is used. When this happened, arg pointer may be eliminated by hard frame pointer. Since hard frame pointer is encoded with DW_OP_fbreg which uses the DW_AT_frame_base attribute, not hard frame pointer directly, we should allow hard frame pointer when generating DWARF info even if frame pointer isn't used. gcc/ PR debug/86593 * dwarf2out.c (based_loc_descr): Allow hard frame pointer even if frame pointer isn't used. (compute_frame_pointer_to_fb_displacement): Likewise. gcc/testsuite/ PR debug/86593 * g++.dg/pr86593.C: New test. --- gcc/dwarf2out.c | 25 ++++++++++++------------- gcc/testsuite/g++.dg/pr86593.C | 11 +++++++++++ 2 files changed, 23 insertions(+), 13 deletions(-) create mode 100644 gcc/testsuite/g++.dg/pr86593.C diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c index 77317ed2575..40cfdf56337 100644 --- a/gcc/dwarf2out.c +++ b/gcc/dwarf2out.c @@ -14325,13 +14325,13 @@ based_loc_descr (rtx reg, poly_int64 offset, if (elim != reg) { + /* Allow hard frame pointer here even if frame pointer + isn't used since hard frame pointer is encoded with + DW_OP_fbreg which uses the DW_AT_frame_base attribute, + not hard frame pointer directly. */ elim = strip_offset_and_add (elim, &offset); - gcc_assert ((SUPPORTS_STACK_ALIGNMENT - && (elim == hard_frame_pointer_rtx - || elim == stack_pointer_rtx)) - || elim == (frame_pointer_needed - ? hard_frame_pointer_rtx - : stack_pointer_rtx)); + gcc_assert (elim == hard_frame_pointer_rtx + || elim == stack_pointer_rtx); /* If drap register is used to align stack, use frame pointer + offset to access stack variables. If stack @@ -20512,14 +20512,13 @@ compute_frame_pointer_to_fb_displacement (poly_int64 offset) in which to eliminate. This is because it's stack pointer isn't directly accessible as a register within the ISA. To work around this, assume that while we cannot provide a proper value for - frame_pointer_fb_offset, we won't need one either. */ + frame_pointer_fb_offset, we won't need one either. We can use + hard frame pointer in debug info even if frame pointer isn't used + since hard frame pointer in debug info is encoded with DW_OP_fbreg + which uses the DW_AT_frame_base attribute, not hard frame pointer + directly. */ frame_pointer_fb_offset_valid - = ((SUPPORTS_STACK_ALIGNMENT - && (elim == hard_frame_pointer_rtx - || elim == stack_pointer_rtx)) - || elim == (frame_pointer_needed - ? hard_frame_pointer_rtx - : stack_pointer_rtx)); + = (elim == hard_frame_pointer_rtx || elim == stack_pointer_rtx); } /* Generate a DW_AT_name attribute given some string value to be included as diff --git a/gcc/testsuite/g++.dg/pr86593.C b/gcc/testsuite/g++.dg/pr86593.C new file mode 100644 index 00000000000..feed8c3743e --- /dev/null +++ b/gcc/testsuite/g++.dg/pr86593.C @@ -0,0 +1,11 @@ +// { dg-options "-O -g -fno-omit-frame-pointer" } + +struct Foo +{ + int bar(int a, int b, int c, int i1, int i2, int i3, int d); +}; + +int Foo::bar(int a, int b, int c, int i1, int i2, int i3, int d) +{ + return 0; +} -- 2.17.1