From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104496 invoked by alias); 1 Aug 2016 10:44:41 -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 104472 invoked by uid 89); 1 Aug 2016 10:44:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_05,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=U*richard.guenther, richard.guenther@gmail.com, richardguenthergmailcom, sk:jakub@r X-HELO: mail-wm0-f47.google.com Received: from mail-wm0-f47.google.com (HELO mail-wm0-f47.google.com) (74.125.82.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 01 Aug 2016 10:44:33 +0000 Received: by mail-wm0-f47.google.com with SMTP id q128so364689974wma.1 for ; Mon, 01 Aug 2016 03:44:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cVQ1LN+RpGsgj0t32DYFPoeJ3WIeztLHFN9jbZPqwZo=; b=SVGVBQsL62dF9uh9qi9ebMN5Q8wIispPdZSNEuzNDwnyWa3IkHFQlHZAq76gAvKPXH QMR+aNqFCt+GlhouGZ+V0JTLAqBGRTknIvGFBGb/oSxrMw4b8B2ZWbmNhFlkQG7ZXuEn sS0BPK+HKv8/6Nf2kOFF15zKOFsT9+ZH9+7x5nWan8rQ/qzF/s/35t0AjU9XfqMibBSv 9cQjH735jxrHqOGWh6pgM9inzWxUYyDufa1vNiPXPztb8oVXcA7M5MeI10Y2DoPHM2L/ 8mP+qYzbIeGnijRC9b5Ujd/jeDYlWANpKUmTPk2fhgG8FvLEfiNZ0q6MZlVVABp7RHXO 7whQ== X-Gm-Message-State: AEkoouu9WY5IVp5fc2moLYhYh70e76ofOLfqAMH1Mfu1TVyXPBhkITLpNECGbCyC0eaf7HlrD5jJyddTSYvHdQ== X-Received: by 10.28.35.86 with SMTP id j83mr53101891wmj.18.1470048270896; Mon, 01 Aug 2016 03:44:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.137.202 with HTTP; Mon, 1 Aug 2016 03:44:30 -0700 (PDT) In-Reply-To: References: <20160721165324.GI7387@tucnak.redhat.com> <20160722120816.GN7387@tucnak.redhat.com> From: Richard Biener Date: Mon, 01 Aug 2016 10:44:00 -0000 Message-ID: Subject: Re: [PATCH] Fix early debug regression with DW_AT_string_length (PR debug/71906) To: Jakub Jelinek Cc: Jason Merrill , Aldy Hernandez , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00034.txt.bz2 On Fri, Jul 22, 2016 at 2:39 PM, Richard Biener wrote: > On Fri, Jul 22, 2016 at 2:08 PM, Jakub Jelinek wrote: >> On Fri, Jul 22, 2016 at 01:55:22PM +0200, Richard Biener wrote: >>> > @@ -19201,18 +19205,70 @@ gen_array_type_die (tree type, dw_die_re >>> > if (size >= 0) >>> > add_AT_unsigned (array_die, DW_AT_byte_size, size); >>> > else if (TYPE_DOMAIN (type) != NULL_TREE >>> > - && TYPE_MAX_VALUE (TYPE_DOMAIN (type)) != NULL_TREE >>> > - && DECL_P (TYPE_MAX_VALUE (TYPE_DOMAIN (type)))) >>> > + && TYPE_MAX_VALUE (TYPE_DOMAIN (type)) != NULL_TREE) >>> > { >>> > tree szdecl = TYPE_MAX_VALUE (TYPE_DOMAIN (type)); >>> > - dw_loc_list_ref loc = loc_list_from_tree (szdecl, 2, NULL); >>> > + tree rszdecl = szdecl; >>> > + HOST_WIDE_INT rsize = 0; >>> > >>> > size = int_size_in_bytes (TREE_TYPE (szdecl)); >>> > - if (loc && size > 0) >>> > + if (!DECL_P (szdecl)) >>> > { >>> > - add_AT_location_description (array_die, DW_AT_string_length, loc); >>> > - if (size != DWARF2_ADDR_SIZE) >>> > - add_AT_unsigned (array_die, DW_AT_byte_size, size); >>> > + if (TREE_CODE (szdecl) == INDIRECT_REF >>> >>> So I wonder how this can happen with variable-size type >>> gimplification. Shouldn't >>> this be on, say, DECL_VALUE_EXPR of the DECL_P TYPE_MAX_VALUE? >> >> If you mean the INDIRECT_REF, that only happens with PARM_DECLs, and >> conceptually a dereference of the argument is the right spot where the >> length lives (if you reallocate the string with different character length, >> then that is where you store the value. If you add some artificial >> decl that will hold the value of *_varb, then the trouble is that the >> variable won't be assigned before the function prologue and most likely will >> be optimized away anyway. > > True. I wonder how other cases look like with the length not based on a > parameter. 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). 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). Thanks, Richard. >>> <1><28d>: Abbrev Number: 19 (DW_TAG_string_type) >>> <1><28e>: Abbrev Number: 19 (DW_TAG_string_type) >>> <1><28f>: Abbrev Number: 6 (DW_TAG_pointer_type) >>> >>> so there is nothing to annotate with a location later. >> >> With the patch there will be DW_OP_call4 in 2 DW_AT_string_length >> attributes and one DW_OP_call4; DW_OP_deref. >> >>> Note that even with GCC 5 'varb' didn't get a DW_AT_string_length, >>> 'vara' did, though. >> >> Yeah, I've mentioned that in the mail. >> >> Jakub