From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::244; helo=mail-it0-x244.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 8C062223522AA for ; Wed, 28 Feb 2018 00:07:17 -0800 (PST) Received: by mail-it0-x244.google.com with SMTP id l187so2453229ith.4 for ; Wed, 28 Feb 2018 00:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h5QIOzDwEmuO0qee0MeUfhSHgqdYhIwy4kKrRibI1mo=; b=k14qnIQ2cXDTH6Vi0zGbUG5hWUdqM1TCh5WH9uqtjlK/Fs8o1R+YhmCBBIsCeKTDBu Bl9GJyZdTby3UeHvEWP+JLiLK2rJQ2nKYX4C4zPSYX5184FueUTeguT2sYWaNYdlzVsI UXQUj2FOfMcKOVR52mrNAbD+oldt9EAX0KW14= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h5QIOzDwEmuO0qee0MeUfhSHgqdYhIwy4kKrRibI1mo=; b=KedjvO0nqr63JAucqEJhJucOYKErzMMqlw8mAymo2jU7w6jg1C/KRRm8r3YPJByl94 VwstmBFGvRmiPWh1mo8rl5PIPHY0luR9zBPL0Is1+Ca39a0q9UC/AljxszJGtI4+nN6E UYOIrdaoIdltAfswlkkpiJ6+BY81/L/5xNpH4cESzDg6ccpS6SJg4bYwxcE5u5lX3QTe jq+MeU8yG78B/GBCrw/bN33u8qJx3X1M2hRz1uHZtqzOerpPVEcrgLvgAz7vy1KKOzaR 3qJDIkny36Z2xcx2esJXlW5DEN+fTfyflkILBsilH9q+LVTMUr9+z51SI3rPVb/0TaG1 1Xcg== X-Gm-Message-State: APf1xPDFuNMcfPLp7gHpM3GovDqMhRH4Vp0j6ecZqOf6PDbqB71nVn0T 5/WsKR2bFNzhxfnVBcB6YpH00WwR3CuGeYXtRPr07Q== X-Google-Smtp-Source: AH8x225k/hfgb9a/bCoffw7mJcHUl89XhqWtpwfGxye04DZGVBQlbpSsdufBr2Lc2T2NwIO+2zpayDHvS63/jDDvm/I= X-Received: by 10.36.217.22 with SMTP id p22mr19915275itg.106.1519805604074; Wed, 28 Feb 2018 00:13:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.138.209 with HTTP; Wed, 28 Feb 2018 00:13:23 -0800 (PST) In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E1D47B8@SHSMSX104.ccr.corp.intel.com> References: <20180227175132.1607-1-ard.biesheuvel@linaro.org> <20180227183327.lg6juoabvbc3jute@bivouac.eciton.net> <20180227185801.6d7mgbkaqtxppcid@bivouac.eciton.net> <20180227200107.6degkvddcd46dlba@bivouac.eciton.net> <4A89E2EF3DFEDB4C8BFDE51014F606A14E1D47B8@SHSMSX104.ccr.corp.intel.com> From: Ard Biesheuvel Date: Wed, 28 Feb 2018 08:13:23 +0000 Message-ID: To: "Gao, Liming" Cc: Leif Lindholm , "edk2-devel@lists.01.org" , "Zhu, Yonghong" Subject: Re: [PATCH] BaseTools/tools_def: use separate PP definition for DTC X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 08:07:18 -0000 Content-Type: text/plain; charset="UTF-8" On 28 February 2018 at 02:41, Gao, Liming wrote: > Reviewed-by: Liming Gao > Thanks all Pushed as a68749f39a2e04ef68e5656b7b72fca25a2e23dc >> -----Original Message----- >> From: Leif Lindholm [mailto:leif.lindholm@linaro.org] >> Sent: Wednesday, February 28, 2018 4:01 AM >> To: Ard Biesheuvel >> Cc: edk2-devel@lists.01.org; Gao, Liming ; Zhu, Yonghong >> Subject: Re: [PATCH] BaseTools/tools_def: use separate PP definition for DTC >> >> On Tue, Feb 27, 2018 at 07:02:06PM +0000, Ard Biesheuvel wrote: >> > On 27 February 2018 at 18:58, Leif Lindholm wrote: >> > > On Tue, Feb 27, 2018 at 06:36:08PM +0000, Ard Biesheuvel wrote: >> > >> On 27 February 2018 at 18:33, Leif Lindholm wrote: >> > >> > On Tue, Feb 27, 2018 at 05:51:32PM +0000, Ard Biesheuvel wrote: >> > >> >> Clang's preprocessor behaves differently from GCC's, and produces >> > >> >> intermediate device tree source that still contains #pragma pack() >> > >> >> and other directives that the device tree compiler chokes on. >> > >> >> >> > >> >> For assembling device tree sources, it matters very little which >> > >> >> preprocessor is being used, so let's just use GNU CPP explicitly. >> > >> > >> > >> > Ah, right, same fundamental issue as >> > >> > 5b8766bb92debfa7b2f45a4a6d683b4227360d66. >> > >> >> > >> Yes, and I fail to see why changing just those two files makes a >> > >> meaningful difference. >> > > >> > > Probably because Secure96Dxe.inf has a lot more [Packages] and >> > > [LibraryClasses] dependencies than DeveloperBox.inf. >> > > >> > > This patch would undoubtedly also have resolved that issue. >> > > (As would clang preprocessor not throwing out C syntax when explicitly >> > > asked to provide asm.) >> > > >> > >> > However, this time triggered by autogen seemingly forcing inclusion of >> > >> > lots of central header files that are not even used, like >> > >> > MdePkg/Include/IndustryStandard/Bluetooth.h >> > >> > MdePkg/Include/IndustryStandard/Acpi10.h >> > >> > and so on. >> > >> > >> > >> > Is there any way to suppress these implicit includes from .dts >> > >> > processing? >> > >> >> > >> There is 'Trim', which can filter #include'd content, but using that >> > >> also robs us of the ability to #include .dtsi files, which was kind of >> > >> the point of using the preprocessor in the first place. >> > > >> > > Yeah, that'd definitely be missing the point slightly. >> > > >> > > I was thinking more along the lines of either excluding the autogen >> > > bits from the preprocessing or using a separate .inf for the .dts. >> > > >> > >> > We need the AutoGen.h bits for the fixed PCD values, which was the >> > other reason for using the preprocessor in the first place. >> >> Yeah, I was afraid of that. >> >> > Separate .inf would mean registering file GUIDs in the package .DEC, >> > so that the driver can find the binary image at runtime, which is what >> > I was trying to get away from by pulling it into the driver, >> > especially because we are dealing with overlay DT snippets, of which >> > there may be many, rather than a single DT (with a well known file >> > GUID) for the entire platform. >> > >> > > If neither of those feels practical, the proposed patch is fine. >> > > It just feels a little bit clunky. >> > >> > Yeah, I don't see any unclunky solutions, unfortunately. >> >> Fair enough. >> Reviewed-by: Leif Lindholm