From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) by sourceware.org (Postfix) with ESMTPS id BCFDC386EC3A for ; Tue, 24 Nov 2020 18:38:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BCFDC386EC3A Received: by mail-io1-xd31.google.com with SMTP id m9so22983341iox.10 for ; Tue, 24 Nov 2020 10:38:39 -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=45VXSiCyELr5edbDbC84YepL0EaTILTkyHNchT20BEk=; b=DnjfAJ2IX5upGcFRIuRYX8lWOuZPNDLDjionBsNQGwOBjy0c6Akuv4rqfbyVxyAmuF 8jJlgpHJiM2aoFZcba1dEVfc6xLIFbSne5cwVyWnbvugPTwiN012nfPwv+B0cFWeR562 3Jf5/Gv+JONP2dOJuhInANhqyI+c2g7jMa6w7ZgPfZYWEetguvyjiMircAA2uGOAU5jv 1Ty4mHYKVKvBdVeEvYRmgq5ncO9UR7hTP4LT8E1VVKtuPnmCTitL8ijfFdUNcqeRnoGf GOlREqraubSYIIXNk3wlzMg/3J4uAHAPawzzb9m6zry90JYJ+DMCCCAP5BBQrmPs5/ku 2oLw== X-Gm-Message-State: AOAM531G81TfZn/x3yyfMFE9ebBYRF+p2UEqGSGRvxVCTc+0evGN4qJU qR+yRlC9orpnlQomOKzheJxyPsjIOYtPqXiAuUo= X-Google-Smtp-Source: ABdhPJwHEmLyaZj7X69+kJgTREQW6PCYM9nak716PRsOrkQhoj0AwY3rX2xL/+dtx/q6qJuzcRBa4tliUvKkt1VDeUk= X-Received: by 2002:a02:354b:: with SMTP id y11mr5512935jae.25.1606243119148; Tue, 24 Nov 2020 10:38:39 -0800 (PST) MIME-Version: 1.0 References: <20201121001937.GE2684@wildebeest.org> <20201124074505.GL3788@tucnak> <2bbab27b8cba9e1938adf6498f1fb1ced9acbd06.camel@klomp.org> <20201124111118.GS3788@tucnak> In-Reply-To: <20201124111118.GS3788@tucnak> From: David Blaikie Date: Tue, 24 Nov 2020 10:38:28 -0800 Message-ID: Subject: Re: DWARF64 gcc/clang flag discussion To: Jakub Jelinek Cc: Mark Wielaard , Richard Biener , "gcc@gcc.gnu.org" , "ikudrin@accesssoftek.com" , Alexander Yermolovich , "maskray@google.com" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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 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: Tue, 24 Nov 2020 18:38:41 -0000 On Tue, Nov 24, 2020 at 3:11 AM Jakub Jelinek wrote: > > On Tue, Nov 24, 2020 at 12:04:45PM +0100, Mark Wielaard wrote: > > Hi, > > > > On Tue, 2020-11-24 at 08:50 +0100, Richard Biener wrote: > > > On Tue, Nov 24, 2020 at 8:45 AM Jakub Jelinek wrote: > > > > I agree with Richard and I'd lean towards -gdwarf32/-gdwarf64, even > > > > when DWARF 32 is released in 81 years from now or how many, it would > > > > use -gdwarf-32. > > > > > > Works for me. Let's go with -gdwarf32/64. > > > > I don't have a strong opinion, so if that is the consensus, lets go > > with that. The only open question (which I wanted to avoid by picking > > -f...) is whether it enables generating debuginfo as is normal when > > using any -goption, or whether you need another -goption to explicitly > > turn on debuginfo generation when using -gdwarf32/64? My preference > > would be that any option starting with -g enables debuginfo generation > > and no additional -g is needed to keep things consistent. > > I think we lost that consistency already, I think -gsplit-dwarf has been > changed quite recently not to imply -g. My understanding was that that change hasn't gone in at this point, in part because of the issue of changing the semantics of an existing flag and discussions around whether -g implies debug info. Could you confirm if this change has been made in GCC? as it may be important to make a similar change in Clang for consistency. Not that Split DWARF would be the first example of -g flags that don't imply -g. (-ggnu-pubnames, I think, comes to mind) > That said, for -gdwarf32/64, I think it is more sensible to enable debug > info than not to. Given my (& I think others on both GCC and Clang from what I gathered from the previous threads) fairly strong desire to allow selecting features without enabling debug info - perhaps it'd make sense for Clang to implement -fdwarf32/64 and then can implement -gdwarf32/64 for compatibility whenever GCC does (without implementing -gdwarf32/64 with potentially differing semantics than GCC re: enabling debug info) Seems these conversations end up with a bunch of different perspectives which is compounding the inconsistencies/variety in flags. If there's general agreement that -g* flags should imply -g, maybe we could carveout the possibility then that -f flags can affect debug info generation but don't enable it? For users who want to be able to change build-wide settings while having potentially per-library/per-file customization. (eg: I want to turn down the debug info emission on this file (to, say, -gmlt) but I don't want to force debug info on for this file regardless of build settings) - Dave