From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) by sourceware.org (Postfix) with ESMTPS id 6452B3858034 for ; Wed, 2 Dec 2020 21:12:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6452B3858034 Received: by mail-il1-x132.google.com with SMTP id q1so2890260ilt.6 for ; Wed, 02 Dec 2020 13:12:14 -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=muqwLFr+WEyfgvLwz6ABWg4dIL+bjzoMnNNZBZ9a7BY=; b=KKx8hd/bToD5EFmVGX4VWn6APyExHKpUpVN8Rz6hl1M2DfXq/GU1+fDDv3O233ecnT n+mre76Vxb1L/fGphgxEDdgx2yXU/32WgVGpecE9FzshAB1n18ZbF+6PaVhZO/+Dp5W2 GUqeGNrKj+/7CwbC+vvkeX9Yifn2fH9p3cE5FxVeWH0gUHUMqoS79flUYuOgaBF/HARE fk2GMchc6ZkYY06uBMOXVyk+lUYG5JgWR1BQoTB8xoJdigg7E8pPC6g9nFnd4E/Bo4UM WT/UfWSdLXtXebzvRMvGPsOnhtDQmsetdTWqkL3R45GCm0D5OJEVVVTFTC0do3xvry+K 2Xww== X-Gm-Message-State: AOAM531O/bksajLCLYVBkuTOxX0NToKVM5zY3NFwYHFeyCsUpzdd5Qjw b78Od5hqEpoo1LZt4VJIk9rm7gmNAFBnJK/D7Ho= X-Google-Smtp-Source: ABdhPJyb8S+Cu28+rVsLIPWQenwBN/ga/RW9jNu+skwjL4z4olZmi+lk6hMZ5bYpgvgyDf6BwRBldwxpWB5Z0VNx1TY= X-Received: by 2002:a05:6e02:128b:: with SMTP id y11mr4099043ilq.75.1606943533819; Wed, 02 Dec 2020 13:12:13 -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: David Blaikie Date: Wed, 2 Dec 2020 13:12:02 -0800 Message-ID: Subject: Re: DWARF64 gcc/clang flag discussion To: Alexander Yermolovich Cc: Richard Biener , Jakub Jelinek , Mark Wielaard , "gcc@gcc.gnu.org" , "ikudrin@accesssoftek.com" , "maskray@google.com" X-Spam-Status: No, score=-2.8 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" 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: Wed, 02 Dec 2020 21:12:16 -0000 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 32bit > should be a default, and 64bit should be used rarely (paraphrasing). So > when user enabled debug information the default expectation is that it will > 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 able > 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 your > interface library you intend to ship to clients who might only have DWARF32 > support, but your library is big and needs DWARF64 for the rest). A general > architectural principle of most command line arguments to the compiler is > 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 info > 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 files > and -g1 on others, and/or under different build modes. And the project as 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 we > added -fdebug-default-version=N (I might be misremembering the spelling) 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" of > 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 their spelling is. > (in addition to their general similarly maybe being a source 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 ago during my > undergrad: "RTFM". If my understanding of exchange on this thread 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. - Dave