From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 7EDCF3857021 for ; Fri, 4 Dec 2020 08:36:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7EDCF3857021 Received: by mail-ej1-x631.google.com with SMTP id n26so7494352eju.6 for ; Fri, 04 Dec 2020 00:36:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6TU7/mJ761t6Rlgw4LlChxOm7AsPXqNSvxL/Yj9zi30=; b=DgKxiWlF/trfObKk4PHLmhxMZ9eXsK/SFCr+8zKB4W0hRCnb/5giyA3L05xa9BIdlk qsVtJ4nlTFxFa0ZvyhCYtzMKu3pLQjMsscfZBUq7AZdOEPsCCSFev/UWxNxeTWWlCqKs ZdZ9gEhcJvKq9vNrqzshyLZ19RZwuA+fBCfvTQi0BenIygu3zUXvHb4LVIZugS/i4SZo qKSK3kYBuklcI/pLqD1Ce3FqFvgDsPHM3wPv9oWPk14iphuRRC9U5jKt7Za0BzH4R5MS xMehksYhkfxB5h/Ib77gtQojQqo/u0k5azBZJuJx7ORV6UULm47yDq/G8CbpIi3RHPHT dUMg== X-Gm-Message-State: AOAM530kSrRLoo2PGQ6kp5046gSIy+Tfxn5WeEy4TT87jRvAnUj/FAOP CIOPa8t32CIMQrgVPGRlRXA7e3SX0xVB2jOOTtc= X-Google-Smtp-Source: ABdhPJwjozvHa+ZCCtXm5/RD85DOXpBvyHsAX8MA5dXJYOZcw5ZCWAoozj3oBAAQ/BsL+RxdvYil0Uvo4rSKOsIZfyU= X-Received: by 2002:a17:906:7d98:: with SMTP id v24mr6187295ejo.129.1607070976179; Fri, 04 Dec 2020 00:36:16 -0800 (PST) MIME-Version: 1.0 References: <20201121001937.GE2684@wildebeest.org> <20201124074505.GL3788@tucnak> <2bbab27b8cba9e1938adf6498f1fb1ced9acbd06.camel@klomp.org> <20201124111118.GS3788@tucnak> In-Reply-To: From: Richard Biener Date: Fri, 4 Dec 2020 09:36:05 +0100 Message-ID: Subject: Re: DWARF64 gcc/clang flag discussion To: David Blaikie Cc: Alexander Yermolovich , Jakub Jelinek , Mark Wielaard , "gcc@gcc.gnu.org" , "ikudrin@accesssoftek.com" , "maskray@google.com" X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 08:36:20 -0000 On Thu, Dec 3, 2020 at 6:52 PM David Blaikie wrote: > > > On Wed, Dec 2, 2020 at 5:10 PM Alexander Yermolovich > wrote: > >> >> >> ------------------------------ >> *From:* David Blaikie >> *Sent:* Wednesday, December 2, 2020 1:12 PM >> *To:* Alexander Yermolovich >> *Cc:* Richard Biener ; Jakub Jelinek < >> jakub@redhat.com>; Mark Wielaard ; gcc@gcc.gnu.org < >> gcc@gcc.gnu.org>; ikudrin@accesssoftek.com ; >> maskray@google.com >> *Subject:* Re: DWARF64 gcc/clang flag discussion >> >> >> >> On Wed, Dec 2, 2020 at 10:44 AM Alexander Yermolovich >> wrote: >> >> >> >> ------------------------------ >> *From:* David Blaikie >> *Sent:* Tuesday, December 1, 2020 10:33 AM >> *To:* Alexander Yermolovich >> *Cc:* Richard Biener ; Jakub Jelinek < >> jakub@redhat.com>; Mark Wielaard ; gcc@gcc.gnu.org < >> gcc@gcc.gnu.org>; ikudrin@accesssoftek.com ; >> maskray@google.com >> *Subject:* Re: DWARF64 gcc/clang flag discussion >> >> >> >> On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich >> wrote: >> >> >> >> ------------------------------ >> *From:* David Blaikie >> *Sent:* Monday, November 30, 2020 12:09 PM >> *To:* Alexander Yermolovich >> *Cc:* Richard Biener ; Jakub Jelinek < >> jakub@redhat.com>; Mark Wielaard ; gcc@gcc.gnu.org < >> gcc@gcc.gnu.org>; ikudrin@accesssoftek.com ; >> maskray@google.com >> *Subject:* Re: DWARF64 gcc/clang flag discussion >> >> On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich >> wrote: >> >> Thank you David for driving the conversation, sorry I was on vacation. >> >> >> All good - really appreciate everyone chipping in whenever/however they >> can! >> >> >> >> I guess discussion is from perspective of having both flags >> gdwarf32/gdwarf64. In which case it's a valid question on whether they >> should imply -g like -gdwarf-#. >> But can this be viewed as only a -gdwarf64 flag, that is a qualifier to >> other debug flags that enable debug information? DWARF spec says that 32= bit >> should be a default, and 64bit should be used rarely (paraphrasing). So >> when user enabled debug information the default expectation is that it w= ill >> be 32bit. There is no real need for a flag to say "I want debug >> information, and I want it 32bit". >> >> >> I'm not quite with you here, I think. I believe it's important to be abl= e >> to opt into and out of things at any point on the command line - because= of >> how complex build systems build up command lines. You might have a >> -gdwarf64 set as a project default, but for some reason want to opt into >> -gdwarf32 in other parts (perhaps you're building the debug info for you= r >> interface library you intend to ship to clients who might only have DWAR= F32 >> support, but your library is big and needs DWARF64 for the rest). A gene= ral >> architectural principle of most command line arguments to the compiler i= s >> that they can be opted into/out of fairly symmetrically (hence all the >> -*no-* variant flags). >> >> [Alex] Ah I see, good point. >> >> >> On the other hand, 64bit DWARF format must be enabled. So from users >> perspective it's "I want debug information enabled for particular DWARF >> version and level, oh and I want it to be 64bit". >> >> >> But there's also the possibility of wanting to turn on DWARF64 for any >> debug info in your build, but not necessarily wanting to turn on debug i= nfo >> while doing so. Eg: you have a big build system, with a variety of users >> and flags all over the place - maybe users opting in to -g2 on some file= s >> and -g1 on others, and/or under different build modes. And the project a= s a >> whole is reaching the DWARF64 tipping point and you'd like to say "if we= 're >> generating DWARF, make it DWARF64". We've recently encountered this sort= of >> situation with -gsplit-dwarf and with -gdwarf-N (in switching to DWARFv5= we >> had this situation where there's a big code base/build system with many >> users, many uses of different -gN-type flags and it'd be impractical to = go >> and add -gdwarf-5 to all the -gN uses to make them all use DWARFv5, so w= e >> added -fdebug-default-version=3DN (I might be misremembering the spellin= g) to >> Clang to support this use case of "If we're generating DWARF, make it >> DWARFv5") >> >> [Alex] I think we are saying similar thing. The -gdwarf64 doesn't enable >> debug generation, but if it is enabled it will be 64bit. A "qualifier" o= f >> sorts. >> >> >> OK. My concern there, though I think it's the preferable semantics for >> the -gdwarf64 flag when considered in isolation, is now -gdwarf64 and >> -gdwarf-5 would have some fairly subtly different semantics (the latter >> enables debug info and the former does not) in contrast to how close the= ir >> spelling is. (in addition to their general similarly maybe being a sourc= e >> of confusion - even if the numbers aren't close to each other) >> [Alex] That is a good point, but I guess broader question is if >> precedence is not good, should we follow it? If it's clearly documented, >> might be OK. As my professor Brian Harvey said many, many, many moons ag= o >> during my undergrad: "RTFM". If my understanding of exchange on this thr= ead >> is correct, there doesn't seem to be a consensus on this point. >> >> >> Re: lacking consensus: yep. That's my understanding. >> >> Admittedly my sort of wedge take on this is - why not use -f flags that >> don't have the ambiguity/overlap with "maybe it enables debug info too".= (& >> maybe we could use -fdwarf32/64 in Clang, to avoid implementing >> -gdwarf32/64 with a difference in behavior in terms of >> also-enables-emission - then implement whatever semantics GCC ended up >> picking) - well, "why not" because of the general take that debug info >> flags should be "-g", fair enough. >> >> So, yeah, I'm still pretty undecided about how Clang should move forward >> with this in the immediate future. >> [Alex] Well if there is no consensus maybe clang can trail blaze. =F0=9F= =99=82 >> > > My concern with doing so is both that GCC might not make the same > decision, leading to differences in flag semantics (and my other concerns > about the available options that lean towards the -g* style naming and th= e > ambiguities around composability or implied -g in general and in particul= ar > with the likely names here and how close they are to existing names that = do > imply -g, hence my personal preference towards the -f names). Might end u= p > going with the -f names out of a combination of my desire for clear > designation of composability, and sidestepping the issue of GCC > compatibility in the future if GCC's going to pick a -g name and semantic= s > (implied -g or otherwise) anyway. This does mean I/we/clang loses a chanc= e > to perhaps somewhat more heavily (than just my words here) influence GCC'= s > flag choice (eg: by Clang choosing the -g* naming and making it composabl= e, > for instance), but avoids the chance of divergent behavior between the tw= o > compilers, or breaking backwards compatibility to maintain compatibility. > > All up I just don't have great feelings about any of the paths forward, > really. I think -fdwarf32/64 is the better option for users, that > -gdwarf32/64 implying -g would be unfortunate (composability is valuable) > and -gdwarf32/64 being composable would be pretty confusing to users give= n > -gdwarf-N isn't composable & they are very similar flags/spellings > (similarly for -g32/64 compared to -gN). > > > Sorry, just going around in circles a bit, I guess this may be a better > summary: > If I had to pick a -g flag/semantic for this, I guess I'd pick > -gdwarf32/64 without implied -g. I'd pick that if I knew GCC would > implement it to match - but if GCC might go either way on implied -g, I > think I'd rather avoid changing the semantics of the flag later on & use = a > different name GCC isn't likely to define different semantics for (and I'= d > probably pick -fdwarf32/64). > There's an approved patch to add -gdwarf{32,64} not implying -g Richard. > > - Dave > >>