From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29455 invoked by alias); 20 Oct 2016 16:21:56 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 29443 invoked by uid 89); 20 Oct 2016 16:21:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=banana, UD:gdb.cp, gdbcp, gdb.cp X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Oct 2016 16:21:46 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C98F316; Thu, 20 Oct 2016 09:21:43 -0700 (PDT) Received: from [10.2.206.246] (e107157-lin.cambridge.arm.com [10.2.206.246]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 218BB3F218; Thu, 20 Oct 2016 09:21:42 -0700 (PDT) Subject: Re: [C++ PATCH] RFC: implement P0386R2 - C++17 inline variables To: gcc-patches@gcc.gnu.org References: <20161011133941.GV7282@tucnak.redhat.com> Cc: jason@redhat.com, Jakub Jelinek From: "Andre Vieira (lists)" Message-ID: <5808EF13.6050702@arm.com> Date: Thu, 20 Oct 2016 16:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg01668.txt.bz2 On 13/10/16 20:34, Jason Merrill wrote: > On Tue, Oct 11, 2016 at 9:39 AM, Jakub Jelinek wrote: > >> And, as mentioned in the DWARF mailing list, I think we should emit >> DW_AT_inline on the inline vars (both explicit and implicit - static >> constexpr data members in C++17 mode). I hope that can be done as a >> follow-up. > > Makes sense. > As I write this I have been waiting for my registration email for the DWARF mailing list, so I havent seen the email you sent. I was wondering whether the regressions I'm picking up for arm-none-eabi-gdb are related to the change in behavior you are suggesting. These are the fails: $9 = {static s = 10, _vptr.A = 0xbb14 , c = 120 'x', j = 33, jj = 1331, s = 47892}^M (gdb) FAIL: gdb.cp/member-ptr.exp: print a (j = 33) ... $12 = {static s = 10, _vptr.A = 0xbb14 , c = 120 'x', j = 44, jj = 1331, s = 47892}^M (gdb) FAIL: gdb.cp/member-ptr.exp: print a (j = 44) The logs used to read: $9 = {_vptr.A = 0xbb44 , c = 120 'x', j = 33, jj = 1331, static s = 10}^M (gdb) PASS: gdb.cp/member-ptr.exp: print a (j = 33) ... $12 = {_vptr.A = 0xbb44 , c = 120 'x', j = 44, jj = 1331, static s = 10}^M (gdb) PASS: gdb.cp/member-ptr.exp: print a (j = 44) As you see the Classe's structure has changed. After bisecting GCC it does seem it's this patch that causes the change in debug information. I did the following to inspect the debug information (renaming A to BANANA, to make it easier to search): $ cp src/binutils-gdb/gdb/testsuite/gdb.cp/member-ptr.cc t.c $ sed -i "s/A/BANANA/g" t.c $ arm-none-eabi-g++ -c -g -mthumb -mcpu=cortex-m3 t.c $ arm-none-eabi-g++ t.o -g -lm -specs=rdimon.specs -lc -lg -lrdimon -mthumb -mcpu=cortex-m3 $ arm-none-eabi-readelf -wi a.out Before this patch you see BANANA's first DW_TAG_MEMBER is '_vptr.BANANA' and there is only one DW_TAG_MEMBER entry for the 'static s'. Whereas after this patch you see the first DW_TAG_MEMBER is: <2><8be>: Abbrev Number: 34 (DW_TAG_member) <8bf> DW_AT_name : s <8c1> DW_AT_decl_file : 1 <8c2> DW_AT_decl_line : 40 <8c3> DW_AT_type : <0x5d> <8c7> DW_AT_external : 1 <8c7> DW_AT_accessibility: 1 (public) <8c8> DW_AT_declaration : 1 the 'static s' that used to be the last, followed by '_vptr.BANANA' and its last DW_TAG_MEMBER is: <2><8f5>: Abbrev Number: 38 (DW_TAG_member) <8f6> DW_AT_specification: <0x8be> <8fa> DW_AT_linkage_name: (indirect string, offset: 0x4a0): _ZN6BANANA1sE <8fe> DW_AT_location : 5 byte block: 3 64 bf 1 0 (DW_OP_addr: 1bf64) I haven't tested it on other targets. Is this expected behavior? Regards, Andre