From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52004 invoked by alias); 11 Aug 2016 14:09:03 -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 51992 invoked by uid 89); 11 Aug 2016 14:09:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=late X-HELO: mail-wm0-f50.google.com Received: from mail-wm0-f50.google.com (HELO mail-wm0-f50.google.com) (74.125.82.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 11 Aug 2016 14:08:59 +0000 Received: by mail-wm0-f50.google.com with SMTP id f65so2405925wmi.0 for ; Thu, 11 Aug 2016 07:08:59 -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=cMMwZ8j2cIx/7jN+XxZi5OmV3mC5MBBirEDpNNu9nr8=; b=Ma6quA40uHAbhWiYn/iqxwfwGpcDls21PK8R2ZAjj4euTFSo71wPtdAfMoqjYFl53J PotcdvxsAsHncAhXmPoDMG2Tv/SJQWW10YTAqCvSNPDSMx6iWXrYJcwLb1y3WZ/XFsHS osS5psycBVq0EQFkIvjfGrYY31B3ZXSvOA51A4RiF1w9p8y6I5zz/BNVfKjdB9+N3ipU 3CPt5m9TC+nfWlIkiFzlyRlriye9oVzLz9sZSQJ0iVOWwThgfFnQZM/xmz23rssXMHh7 gHRXGTzzro34s4kN+TiC3wyufD0VVncT2YM+wHqL3BQTs81VFOZb5cuC4RXQXnQtM+Gh fz3w== X-Gm-Message-State: AEkoousyj75wFlW1bvARSIOdUEQI5CWiDscl2xWggvO4hM3r1BwzDdNGfRLF4ISpNAK1ChzmA24A7iouQpd4OA== X-Received: by 10.194.77.142 with SMTP id s14mr9569613wjw.77.1470924535746; Thu, 11 Aug 2016 07:08:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.137.202 with HTTP; Thu, 11 Aug 2016 07:08:54 -0700 (PDT) In-Reply-To: <20160811123606.GQ14857@tucnak.redhat.com> References: <20160721165324.GI7387@tucnak.redhat.com> <20160722120816.GN7387@tucnak.redhat.com> <20160809143624.GW14857@tucnak.redhat.com> <082C92EB-A15B-4776-AA5A-8C1DB29E9B00@gmail.com> <20160810081655.GG14857@tucnak.redhat.com> <20160811123606.GQ14857@tucnak.redhat.com> From: Richard Biener Date: Thu, 11 Aug 2016 14:09: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/msg00920.txt.bz2 On Thu, Aug 11, 2016 at 2:36 PM, Jakub Jelinek wrote: > Hi! > > On Wed, Aug 10, 2016 at 12:23:06PM +0200, Richard Biener wrote: >> > Introducing another attribute that does the same thing as existing attribute >> > would be way too ugly. In theory the reference class could be added to >> > DW_AT_string_length, I can ask on DWARF workgroup (but it might be too late >> > for DWARF 5), but that still doesn't solve the issue of the indirect params. >> > >> > How do you want to handle the debug info without ammending the early-generated >> > DWARF though? Just by using it as abstract origins of everything and >> > ammending in copies? >> >> Yes. > > I've filed an enhancement request and got one positive feedback, but it is > going to be multiple months at best. > So, at least for non-LTO I'd strongly prefer to go with what the current > patch does, and for LTO we'd then have to ask GDB to implement the reference > class for DW_AT_string_length and then just use that instead, depending on > flag_lto or similar, or perhaps for dwarf4 and earlier don't emit for LTO > variable string length and keep it only for dwarf5+ (if the change is > approved). For the indirect parms and LTO, I guess we'd need to create some > artificial VAR_DECL at function scope with DECL_VALUE_EXPR of *parm, > DECL_ARTIFICIAL, DECL_NAMELESS and reference that instead of the parm > itself. > With this, do you object to the current patch? No, I still hope it avoids generating references to possibly optimized out stuff early - I didn't thorougly review it. I guess I'll find out soon ;) Richard. > Jakub