From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118487 invoked by alias); 9 Aug 2016 14:36:35 -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 118432 invoked by uid 89); 9 Aug 2016 14:36:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=dies, DIE, late X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 09 Aug 2016 14:36:32 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BDF6548D; Tue, 9 Aug 2016 14:36:30 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-204-43.brq.redhat.com [10.40.204.43]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u79EaS2u004374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Aug 2016 10:36:29 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id u79EaQ4M013552; Tue, 9 Aug 2016 16:36:27 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id u79EaO4a013551; Tue, 9 Aug 2016 16:36:24 +0200 Date: Tue, 09 Aug 2016 14:36:00 -0000 From: Jakub Jelinek To: Richard Biener Cc: Jason Merrill , Aldy Hernandez , GCC Patches Subject: Re: [PATCH] Fix early debug regression with DW_AT_string_length (PR debug/71906) Message-ID: <20160809143624.GW14857@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20160721165324.GI7387@tucnak.redhat.com> <20160722120816.GN7387@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00722.txt.bz2 On Mon, Aug 01, 2016 at 12:44:30PM +0200, Richard Biener wrote: > Note that reading the dwarf standard, it looks like it accepts a location > which means we could do an implicit location description using > DW_OP_stack_value which gives us access to arbitrary dwarf > expressions (and thus the possibility to handle it similar to VLAs). Sure. But for the DW_AT_string_length, the issue is that with early debug, we want the attribute early, but locations within a function obviously can be provided late, after the function is compiled. Which is why the patch uses DW_OP_call4 as the holder of the information that the string length is provided by the value of some variable. In certain cases it can stay that way even during late debug, if the var disappears or has no location info etc., then DW_AT_string_length is dropped, or in other cases the location of the var is copied into the attribute etc. This is different from the VLA bounds in DW_AT_upper_bound etc., where it is allowed to just refer to a DIE that holds the value (so we can stick it into the attribute early and just supply the var's location later), for DW_AT_string_length it is not allowed. > But maybe I am missing something? (now running into the issue > with LTO debug and gfortran.dg/save_5.f90 where during early debug > we emit a location that ends up refering to a symbol that might be > optimized away later - early debug cannot sanitize referenced symbols > via resolv_addr obviously). Annotating the DIE late is also not > what I want to do as I'd need to pull in all type DIEs into the late CU > that way (well, at least selected ones, but I'm really trying to avoid > going down that route). In some cases like location of file scope vars, or this DW_AT_string_length, you really need to adjust late the debug info created early, there is no workaround for that. Jakub