From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64178 invoked by alias); 10 Aug 2016 10:23:13 -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 64160 invoked by uid 89); 10 Aug 2016 10:23:11 -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=scalable, Hx-languages-length:2169, late X-HELO: mail-wm0-f54.google.com Received: from mail-wm0-f54.google.com (HELO mail-wm0-f54.google.com) (74.125.82.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 10 Aug 2016 10:23:10 +0000 Received: by mail-wm0-f54.google.com with SMTP id q128so12263063wma.1 for ; Wed, 10 Aug 2016 03:23:09 -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=c/LFoYI/D2tmd/kQGBQOuisWE3OhPBxwiRR6A5TwVOs=; b=VxUWaXqJ81NUVSUzxHeE22cV+bDqynxtUXMFvIoVDSZZkG5D4iu/5XmRuqMGcrBNr2 taZtlWQUuA4oMBa4vB0zXeRfHedsWy1KugqbNyh2XxsKYaCCZGuQTjxfI/31Zg+kuOun KASu9SKKUiV3EhUjBwpB/jpV40JOPn11r1mtgmSoX0RPK4/U6MwPJ0AwPC3Js22LjGTy B3kZo7Y+jggjVsa5nN0FZnnxgk8QtSKXEJ1Dg4IXWhUrk8o9ywyhlto5dzkqFHv8sjhb 5J9/MXyfpodYam/4FQhqw3SaxEbEAnjLldaQ3gW70WacbgOgMl39DAt86yBxdA4/c0i1 IFOQ== X-Gm-Message-State: AEkoouuDMDP9S0w3KVd2xgN+hzj9uvvd6diwVSmgWmldXOx+Fp4F6wX8aQfqBUpm27x8XNtRvHLc7Ijto2lK6A== X-Received: by 10.28.9.194 with SMTP id 185mr2297831wmj.37.1470824587430; Wed, 10 Aug 2016 03:23:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.137.202 with HTTP; Wed, 10 Aug 2016 03:23:06 -0700 (PDT) In-Reply-To: <20160810081655.GG14857@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> From: Richard Biener Date: Wed, 10 Aug 2016 10:23: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/msg00795.txt.bz2 On Wed, Aug 10, 2016 at 10:16 AM, Jakub Jelinek wrote: > On Tue, Aug 09, 2016 at 07:10:34PM +0200, Richard Biener wrote: >> >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. >> >> I suppose the workaround is to fix/extend DWARF... (DW_AT_GNU_string_length that allows us to refer to another DIE?) > > 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. > That would be a total mess for all the consumers... > Parsing DWARF and rewriting it isn't all that hard. It may be not hard but it takes time and bloats debug info. You'd need to do it N times (each LTRANS unit would need to parse all early generated debug, pickle the "interesting" pieces, annotate it and then hopefully write out a lot less than parsed). Or you do what I do, annotate via abstract origins. A clever DWARF optimizer might then do what you suggest on the final executable (smash all copies with their abstract origin). I'm not objecting to the latter, but that's not my primary objective. My primary objective is to make C++ debugging reasonable even when you use LTO - with my prototype patches now all libstdc++ pretty-printer tests PASS while the currently just FAIL. Yes, I do have some DWARF consumer issues - VLAs don't work, but I got no answer from a mail to gdb last year or the bug I filed a few weeks ago. Yes, lldb immediately crashes when trying to parse the DWARF. Those are the only consumers I have access to. That said, I don't see a way to do scalable "better" debug for LTO. Richard. > > Jakub