From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35012 invoked by alias); 15 Nov 2017 04:54:39 -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 33930 invoked by uid 89); 15 Nov 2017 04:54:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=BAYES_00,KAM_SHORT,KB_WAM_FROM_NAME_SINGLEWORD,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 spammy=chat, sides, sk:DW_AT_s, sk:dw_at_s X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 Nov 2017 04:54:37 +0000 Received: from [10.0.0.11] (192-222-251-162.qc.cable.ebox.net [192.222.251.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id F2B5C1E030; Tue, 14 Nov 2017 23:54:35 -0500 (EST) Subject: Re: [PATCH] Show optimized out local variables in "info locals" To: Yao Qi , Simon Marchi Cc: gdb-patches@sourceware.org References: <1510679293-8244-1-git-send-email-simon.marchi@ericsson.com> From: Simon Marchi Message-ID: <434ca326-5bf7-562c-7445-66b265caf300@simark.ca> Date: Wed, 15 Nov 2017 04:54:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-11/txt/msg00269.txt.bz2 On 2017-11-14 05:44 PM, Yao Qi wrote: > On Tue, Nov 14, 2017 at 5:08 PM, Simon Marchi wrote: >> >> However, this change reveals what I think is a bug in GDB, see: >> >> http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2017-September/004394.html >> > > IMO, it is not necessary to emit DW_TAG_lexical_block in concrete instances. > See comment #4 in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37801 > At least, looks gcc generates unnecessary debug information, and we need > to fix GCC somehow. > > Whether it is a bug in GDB or not, I don't know. The answer depends on it is > *unnecessary* or *wrong* to have DW_TAG_lexical_block in concrete instances. I had an email discussion with some gcc developers (Nathan Sidwell, Richard Biener, Jason Merill) after a chat on IRC. Unfortunately, they answered privately so it's not on dwarf-discuss. I'll try to update the thread on dwarf-discuss with their answers tomorrow, for future reference. But the gist of it was: Richard said: > I think the lexical block is just the function scope itself and the inliner > inserts this BLOCK which then corresponds to the DW_TAG_inlined_subroutine. > I suppose we should avoid emitting that BLOCK itself as a DW_TAG_lexical_block > but use the emitted DW_TAG_inlined_subroutine for that. > > Not sure if I remember the details correctly. > > I don't think the DWARF is invalid btw, with early LTO debug we have plenty of > abstract origins where source and destination context don't match 1:1. We're > just using it as a "get some more info from this DIE" link which I think is > all that is documented as semantics (though the 'inline' term pops up too > often there and the relation to DW_AT_specification is unclear to me though > the latter is restricted to DW_TAG_subroutine AFAIR). Jason said (replying to Richard): >> I think the lexical block is just the function scope itself and the inliner >> inserts this BLOCK which then corresponds to the DW_TAG_inlined_subroutine. >> I suppose we should avoid emitting that BLOCK itself as a DW_TAG_lexical_block >> but use the emitted DW_TAG_inlined_subroutine for that. > > Agreed. It's curious that we would generate the lexical block in the > inlined instance and not the abstract. > >> I don't think the DWARF is invalid btw, with early LTO debug we have plenty of >> abstract origins where source and destination context don't match 1:1. We're >> just using it as a "get some more info from this DIE" link which I think is >> all that is documented as semantics (though the 'inline' term pops up too >> often there and the relation to DW_AT_specification is unclear to me though >> the latter is restricted to DW_TAG_subroutine AFAIR). > > Also agreed, GDB ought to be able to handle this situation. > > So, bugs on both sides... So even though there might be something to fix in GCC, I think we'll have to handle the current case in GDB as well. Simon