From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) by sourceware.org (Postfix) with ESMTPS id 117EE3857815 for ; Tue, 1 Dec 2020 01:04:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 117EE3857815 Received: from pps.filterd (m0148461.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0B114S2K023236; Mon, 30 Nov 2020 17:04:35 -0800 Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com with ESMTP id 3547psggvd-10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 30 Nov 2020 17:04:34 -0800 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.36.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 30 Nov 2020 17:04:33 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KmMtMCsVS21iWNtbuGYjJonkLR3IsOksdOsyKhDnXjOJo+SHRFwNb/bfopk2xS2xMB4pZYifxB9OiEa5eAq1DsbX/WR4/drCWCVkOIzPzpW+39t82encWUjL0nWG7DmIMAicMT5A0O5dwa+f/OWUNaN6pXORsbDbxTyZA+FDK6R4lSQ0eX5J7aPHEu3DxC0zRAbZVMBhkV20z3P+q27JZW2mhjMMXscW+7lxh+xFLEQcGA3FVCIzHaSXoEZSHhpwmXbZsoTi8pYl4sQJbiXShoqSGPdRxgoSP+au0obA2sp0BeY9RNoFSY9SlHvRRGrdoS6O1gi97oGOOKNeFqrYSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zEBnbpSEb5fco3ifkMyWYhyyC/XF0jjFp+4bbFTxHpA=; b=nfG+Yql2Fr18Lx0/SBGFWnohn7ypOcC0E44mZ4R/mnnx1I6XloxtcV3BXTEizsh0BYPw2C/latPnYUE4h0sJWudSvsID/3e5Duvh8lAymQ9IyRexdoKj1fJhw+r8Xuj0Vye12Gp7urYzxt/dfr/0gODiDMLEtyv9dgF5ZmtvkqOO3w7lJJkQw8urSEOHYiz3sF1It55ekzi5QnQqjG99Z79PhT8YcDzhR9zgMtPtlLLX7wUuhGWcNw0ZR24DF/mbaJcnuGwxqv/Si2ZMqhKDRjZhh8QNEsAFx/PPob2zsoQl9WdKglGeR9HJ5NQvedag169y4PmpGE3d9M7MwkJzwA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fb.com; dmarc=pass action=none header.from=fb.com; dkim=pass header.d=fb.com; arc=none Received: from BYAPR15MB2470.namprd15.prod.outlook.com (2603:10b6:a02:81::25) by BYAPR15MB2470.namprd15.prod.outlook.com (2603:10b6:a02:81::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.25; Tue, 1 Dec 2020 01:04:32 +0000 Received: from BYAPR15MB2470.namprd15.prod.outlook.com ([fe80::ddec:2c6c:950f:7d4]) by BYAPR15MB2470.namprd15.prod.outlook.com ([fe80::ddec:2c6c:950f:7d4%7]) with mapi id 15.20.3611.025; Tue, 1 Dec 2020 01:04:32 +0000 From: Alexander Yermolovich To: David Blaikie CC: Richard Biener , Jakub Jelinek , Mark Wielaard , "gcc@gcc.gnu.org" , "ikudrin@accesssoftek.com" , "maskray@google.com" Subject: Re: DWARF64 gcc/clang flag discussion Thread-Topic: DWARF64 gcc/clang flag discussion Thread-Index: AQHWv2vXNjh6rwouI0S99cj2pYlJIanRuSWAgAOuQwCAAS95AIAAVbmAgAABjoCAADY7gIAAAdUAgAB88ACAAPcCgIAAz8+AgAevnYyAABDdAIAAT4lN Date: Tue, 1 Dec 2020 01:04:32 +0000 Message-ID: References: <20201121001937.GE2684@wildebeest.org> <20201124074505.GL3788@tucnak> <2bbab27b8cba9e1938adf6498f1fb1ced9acbd06.camel@klomp.org> <20201124111118.GS3788@tucnak> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:400::4:152f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cb7962c3-ae24-4016-02c1-08d89595101a x-ms-traffictypediagnostic: BYAPR15MB2470: x-microsoft-antispam-prvs: x-fb-source: Internal x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UZuh8b5iDRYVrgXx7veDAfk9DPYJM7wX6uUo1Bl9/omW9Im52lrWFmqB3112jq2bxE5BeiVhI0VUbgIszmzVS5+L6LDkr/euE6cWeyIcAfbSKkx4ahJeHX55tlwqX5fHsNGFh+aSqDrGtMIKXtSRtrA4hehxUMMyE9fwRpA1rBdZT/rlcnwTDG7UyEwO825UZ10xDlnsxGvENK+3DBICUDKwMECwb6Xj+O/nIG0UsDnIsOj3xC0EZpPTI36psuICMSd8hZq4UDBobz1Px825cJP05X96oIqqvwax7IqeKEUKuW6nTYS9trZwT/x/DJY5Q4HCcc6kJthRw8/gGaOQmQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR15MB2470.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(366004)(136003)(39860400002)(396003)(52536014)(2906002)(6916009)(5660300002)(4326008)(8676002)(8936002)(19627405001)(6506007)(83380400001)(186003)(53546011)(76116006)(66946007)(33656002)(9686003)(4001150100001)(86362001)(66556008)(7696005)(55016002)(64756008)(54906003)(71200400001)(316002)(66446008)(66476007)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?QNZgikuCSx8pNPLkc+2Gz3VT6DIC0zhUNWK86c7sxA/lUN0xI8DwYSjmgD?= =?iso-8859-1?Q?zpnMKZnrWmG6VG3EohkU9eVeRUrr4QPB6BC29Dz3JThXSdtPzfrvf1frUN?= =?iso-8859-1?Q?MWZ4w/Z8l/exF+P0fKmgk/Zwns1O+isLZrXaXBzF6qs3di5GVHgvQYCtdt?= =?iso-8859-1?Q?tnMv+amDasl3MxeKbbzfUQ7bjreOKF7vwj0G1u7PgFDL9t+8OLZ8jg5zTi?= =?iso-8859-1?Q?7nDA1NFkE8pbyMPOCxwJ9VD3pkR1KnamfHsl6MwqpqPqLvr4ta9g3HeYyc?= =?iso-8859-1?Q?JVo2OHJkZxSY4vY/wmIKnShG97uVy/U9pi6S7azOJTIYAUYs9kgNKqHw81?= =?iso-8859-1?Q?AO/WsRiTLLAEUaiSfjzrveag5LNE1oqwcSMmHQTm0a9ZFGboZpdi/wY/8C?= =?iso-8859-1?Q?D8cGOZPCzx6TNhEzh9YuVAyBdeQ8VMgULMcqfXTqxmzY4U5421lNBe8+vp?= =?iso-8859-1?Q?iKqp8pBFOdjResco718cXhZ4/p1eLVRSZfMsF2wQpGaiqyQZQVuYxEvs/l?= =?iso-8859-1?Q?N+LzDnv71p72e5ou0NDLTG9jVyu1hFsvjA/VOMe7p4xEA38MTKgHqdhTB4?= =?iso-8859-1?Q?hD2Ux2iaGMmX0MG1nD+Df4CcN4VV3V/MpRmugvuXYRdOC/JMSLjpQ2WkAz?= =?iso-8859-1?Q?59U9IFxUk4y8vLjFfUNNCTJWG7a5zGvsJ1OHP4Bk6UdeHS8evWqY5X1LF5?= =?iso-8859-1?Q?lm/At7HQz4O4YayHUB+nfwGWiLszEERkvcS4diYXHX8GLjMDEM5NkrkCto?= =?iso-8859-1?Q?Luj8WCXoXNmURBB4QmKkGvc5sqoBbohtzGDiUl/AJ0qbibKqqyXORflhTk?= =?iso-8859-1?Q?6eNPHbeIkyW3WaVk6385oJbXo2YYinn5IFgPBx6Cgsyf/3wUwdGfNfShBV?= =?iso-8859-1?Q?XXjETvhDXGGyHsANY6mOnIXkr1dCU1a6BXZUTeMNUxPnUMrJ4C6V8MHcNK?= =?iso-8859-1?Q?rB8aHkqrfK64zZzmrVDJZsnxv6t7LFANGK2yf/G4Ukzx6y08C2LTjih5Gd?= =?iso-8859-1?Q?Y1XkIclhTryYTpVK6LvHpqwntO1W2K9cNV4MYO1c4Ep1LROjnDeNK3BH/z?= =?iso-8859-1?Q?sg=3D=3D?= x-ms-exchange-transport-forked: True X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR15MB2470.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cb7962c3-ae24-4016-02c1-08d89595101a X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2020 01:04:32.3922 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nDcNj/SMJFO1fzqOax+UIlfVIHzQqCopTW/ps+9FfZ4IqS08+IQq0QblHQTB1AWX X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2470 X-OriginatorOrg: fb.com X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-30_12:2020-11-30, 2020-11-30 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 impostorscore=0 mlxscore=0 malwarescore=0 spamscore=0 priorityscore=1501 bulkscore=0 mlxlogscore=999 adultscore=0 suspectscore=0 lowpriorityscore=0 phishscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012010004 X-FB-Internal: deliver X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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="iso-8859-1" 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: Tue, 01 Dec 2020 01:04:49 -0000 ________________________________ From: David Blaikie Sent: Monday, November 30, 2020 12:09 PM To: Alexander Yermolovich Cc: Richard Biener ; Jakub Jelinek ; Mark Wielaard ; 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/gdwarf= 64. In which case it's a valid question on whether they should imply -g lik= e -gdwarf-#. But can this be viewed as only a -gdwarf64 flag, that is a qualifier to oth= er debug flags that enable debug information? DWARF spec says that 32bit sh= ould be a default, and 64bit should be used rarely (paraphrasing). So when = user enabled debug information the default expectation is that it will be 3= 2bit. There is no real need for a flag to say "I want debug information, an= d I want it 32bit". I'm not quite with you here, I think. I believe it's important to be able t= o 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 -gdwarf6= 4 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 l= ibrary you intend to ship to clients who might only have DWARF32 support, b= ut your library is big and needs DWARF64 for the rest). A general architect= ural 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 perspe= ctive it's "I want debug information enabled for particular DWARF version a= nd level, oh and I want it to be 64bit". But there's also the possibility of wanting to turn on DWARF64 for any debu= g info in your build, but not necessarily wanting to turn on debug info whi= le doing so. Eg: you have a big build system, with a variety of users and f= lags all over the place - maybe users opting in to -g2 on some files and -g= 1 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 gene= rating DWARF, make it DWARF64". We've recently encountered this sort of sit= uation with -gsplit-dwarf and with -gdwarf-N (in switching to DWARFv5 we ha= d 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 a= dd -gdwarf-5 to all the -gN uses to make them all use DWARFv5, so we added = -fdebug-default-version=3DN (I might be misremembering the spelling) to Cla= ng 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 de= bug generation, but if it is enabled it will be 64bit. A "qualifier" of sor= ts. This also helps to avoid the scenario if user explicitly specifies debug le= vel. The gcc documentation says "If you use multiple -g options, with or without level numbers, the last su= ch option is the one that is effective." With complex, like buck, build systems with various config files, and hard = coded overrides that's just asking to end up with debug level that might no= t be what user expects. Not quite sure I'm following here - if -gdwarf64 does enable -g by default = it might be quite confusing in such a big complicated build system - where = a user actually wanted -gmlt or -g0 or some certain library or file, but it= got overriden by -gdwarf64. (or the inverse - does -gdwarf64 -g mean DWARF= 32 again because that's the default? That's probably not what people want m= ost of the time (but sometimes they might want to opt back into DWARF32 lat= er in the command line) [Alex] Primarily from the debug level perspective. If user specifies -g0 or= -gmlt, and -gdwarf64 (assuming it enables -g), then depending on the order= in command line where build system has put things user might end up with l= evel of debug information they wanted, or with default -g. Basically, I am arguing for case of -gdwarf32/64 not enabling -g. - Dave Thank You Alex ________________________________ From: David Blaikie > Sent: Wednesday, November 25, 2020 1:46 PM To: Richard Biener > Cc: Jakub Jelinek >; Mark Wielaar= d >; gcc@gcc.gnu.org >; ikudrin@accesssoftek.com= >; Alexander Yermolovich >; maskray@google.com > Subject: Re: DWARF64 gcc/clang flag discussion 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 picki= ng > > > > -f...) is whether it enables generating debuginfo as is normal when > > > > using any -goption, or whether you need another -goption to explici= tly > > > > turn on debuginfo generation when using -gdwarf32/64? My preference > > > > would be that any option starting with -g enables debuginfo generat= ion > > > > and no additional -g is needed to keep things consistent. > > > > > > I think we lost that consistency already, I think -gsplit-dwarf has b= een > > > 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 de= bug > > > 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