From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) by sourceware.org (Postfix) with ESMTPS id 05E4B385780E for ; Wed, 25 Nov 2020 21:46:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 05E4B385780E Received: by mail-io1-xd2a.google.com with SMTP id o8so3639358ioh.0 for ; Wed, 25 Nov 2020 13:46:31 -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=xrrVZT7zdpdm+ea6PGyb4iB9wniV9IL+YefhVQ7d8wM=; b=OAfYT3oXRyUTTNnWfGKLGQF+l288aNoC0II75lRoeTzLmX267Dp3jFWP6E2gxPxEa5 ngirXzK7jHKuAEOknluk2lp+g1FgXGMbVZroLrIoG7Zxgyq6J09NaZrb38ASw0jVOpsV WLjnSSwlFYGKo6h32ChHyotgPmF5IbKskiMj3y6nhj3cw+/2l4cWacVdsbqVkNrGRePT qwcJYa4UCRVgR05WJD/vpU+rbuJdO5dUbHSNs5NUA/vt+SdrjhdkAp2a5BzzmymhKLxL 05W40fQ0QG+Ad9y7ojeBwUSmJuDYcSbx6j2t3Vehc5b33PyacA3n8QUmg3mDC1F/392i vPGA== X-Gm-Message-State: AOAM530owMl6LktbccJdURiACA2E1L+exE7+AHs23UVlqNaUsrrRvwi5 sFxmPZT5bwL8flMax8mRFI5UhP6RU7IJSHLg2Xw= X-Google-Smtp-Source: ABdhPJwIWeK1S7+uFduc8MyXsHpQm6Fvx1DwpspALkLM9jcCIdZNpPoEwR8kmq/0FZA50pYWZHBC8W1oQjcuDmmSoJU= X-Received: by 2002:a6b:4401:: with SMTP id r1mr4274040ioa.78.1606340790439; Wed, 25 Nov 2020 13:46:30 -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, 25 Nov 2020 13:46:19 -0800 Message-ID: Subject: Re: DWARF64 gcc/clang flag discussion To: Richard Biener Cc: Jakub Jelinek , Mark Wielaard , "gcc@gcc.gnu.org" , "ikudrin@accesssoftek.com" , Alexander Yermolovich , "maskray@google.com" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.4 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: Wed, 25 Nov 2020 21:46:32 -0000 On Wed, Nov 25, 2020 at 1:22 AM Richard Biener wrote: > > On Tue, Nov 24, 2020 at 7:38 PM David Blaikie wrote: > > > > 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) > > I don't think that all -g switches have to enable debuginfo generation. Any thoughts on this case - whether -gdwarf32/-gdwarf64 should imply -g? > Historically the -g flags selecting a debuginfo format did and I guess > we need to continue to do that for backward compatibility (-gdwarf, > -gstabs, etc.). -gdwarf-N sort of falls under this category, at least for backwards compatibility - though whether it "selects a debuginfo format" might be a bit open to interpretation. Where does -gdwarf32/-gdwarf64 fall on that spectrum for you? I guess the important part is compatibility, not whether it selects a debug info format or does something else. There's no need for mechanical compatibility (though possibly for human compatibility - having -gdwarf-4 enable -g but -gdwarf32 not enable -g seems fairly subtle to me) here, but some folks on this thread suggest -gdwarf32 should enable -g (Jakub and Jeff). > All other -g flags should not enable debug and some > clearly don't, like -gcolumn-info which is even enabled by default. > Also -gno-pubnames does not disable debug. > > From looking at the source the following options enable debug: > > -g > -gN > -gdwarf > -gdwarf-N > -ggdb > -gstabs > -gstabs+ > -gvms > -gxcoff > -gxcoff+ > > all others do not. And yes, the -gsplit-dwarf change went in. Oh. Seems a pity from a backwards (& sidewards with clang - though we'll probably update ours to match to reduce that problem) compatibility standpoint, but good to know! - Dave