From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 7E57C7803CE for ; Tue, 12 Dec 2023 07:49:42 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=sDBSrSEXDt22ZaHaS1SCxIy+yTKPz2y7kMD090TE+ok=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20140610; t=1702367381; v=1; b=kYrQlZkGoL5A4sTq3bnjBrKeuaT8FsEdm3sdIYhgcNf/D3Yra185r235rtgAK+CDxmcj4OjK XiYYpCeuUWukwybU7MqhlKtlH4J4pcAkrbrfGmunMYPRj0BCv+beLSxbyIk3q3aeL/sWrG1Mavn ig0dsAeSmLHyl7YdaB2fEIWU= X-Received: by 127.0.0.2 with SMTP id EEbzYY7687511xDNiYimoe7s; Mon, 11 Dec 2023 23:49:41 -0800 X-Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web11.11754.1702367380058286124 for ; Mon, 11 Dec 2023 23:49:40 -0800 X-Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 16D03B81088 for ; Tue, 12 Dec 2023 07:49:38 +0000 (UTC) X-Received: by smtp.kernel.org (Postfix) with ESMTPSA id 736E4C433C8 for ; Tue, 12 Dec 2023 07:49:37 +0000 (UTC) X-Received: by mail-lj1-f177.google.com with SMTP id 38308e7fff4ca-2cb20c82a79so52646611fa.3 for ; Mon, 11 Dec 2023 23:49:37 -0800 (PST) X-Gm-Message-State: DjqMjGDcqLtGuxoWBHR8nQ6Sx7686176AA= X-Google-Smtp-Source: AGHT+IGVruWDiZUztOKOuzhFAovhRHzsQgdSVtxrDFxNaLQ23V1HLwi87LTvGm+N1chavXKinmQQsyhCtLp0dJaLRpw= X-Received: by 2002:a2e:8619:0:b0:2c9:f7fe:928f with SMTP id a25-20020a2e8619000000b002c9f7fe928fmr2177772lji.93.1702367375704; Mon, 11 Dec 2023 23:49:35 -0800 (PST) MIME-Version: 1.0 References: <20231210101859.19198-1-mjsbeaton@gmail.com> <9b333ba1-7ce6-5be7-6482-3aadef7f1973@redhat.com> <12387048-80bf-87db-c15e-55583678863f@redhat.com> <1a51ab01-6a06-af3d-5068-86e6668fd6ec@redhat.com> In-Reply-To: From: "Ard Biesheuvel" Date: Tue, 12 Dec 2023 08:49:24 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH] BaseTools/tools_def: Disable unneeded-internal-declaration warning in CLANGPDB To: Mike Beaton Cc: Laszlo Ersek , devel@edk2.groups.io, Ard Biesheuvel Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,ardb@kernel.org List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=kYrQlZkG; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On Tue, 12 Dec 2023 at 08:17, Mike Beaton wrote: > > > > A completely different approach, which allows clang to spot that the > > > usage has been 'optimised away' and so to not complain (and therefore > > > allows us to re-enable the warning in CLANGDWARF as well), is the > > > following: > > > > > > --- a/MdePkg/Include/Library/DebugLib.h > > > +++ b/MdePkg/Include/Library/DebugLib.h > > > @@ -426,7 +426,10 @@ UnitTestDebugAssert ( > > > } \ > > > } while (FALSE) > > > #else > > > -#define DEBUG(Expression) > > > +#define DEBUG(Expression) \ > > > + if (FALSE) { \ > > > + _DEBUG (Expression); \ > > > + } > > > #endif > > > > > > /** > > > > > > > But will this not litter the object files with a bunch of format strings > > etc? > > Yes. Which would be optimized away at link time. (Or rather, I believe > so, would need further tests to confirm exactly what is optimized away > when.) > Link time optimization does not usually optimize away assets at this granularity. Even if --gc-sections is set, the only thing it can optimize away is an entire input section. However, the compiler should be smart enough not to emit any references to format strings etc in the first place, as it knows the condition can never become true (but NOOPT builds should retain them). > > It feels like, for CLANGPDB (and maybe CLANGDWARF), the RELEASE target > > should not define MDEPKG_NDEBUG, but make sure (instead) that > > DebugPrintEnabled() evals to FALSE. If PcdDebugPropertyMask is > > fixed-at-build, then DebugPrintEnabled() should be possible to evaluate > > at compile time; is that right? (At least for clang?) > > Yes, that is my understanding of how compile-time Pcds work too - but > wouldn't the net result be the same as what I suggested? It depends on the kind of access. For PCDs that are fixed-at-build only, the FixedPcdGet###() accessors will evaluate to constant preprocessor expressions, allowing the compiler to do optimizations. The ordinary PcdGet###() routines will not produce compile time constant expressions in the same way, so there, all the logic is retained (again, modulo LTO) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#112359): https://edk2.groups.io/g/devel/message/112359 Mute This Topic: https://groups.io/mt/103087794/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-