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::241; helo=mail-it0-x241.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 41AB120955F0F for ; Tue, 27 Feb 2018 10:56:01 -0800 (PST) Received: by mail-it0-x241.google.com with SMTP id v194so471195itb.0 for ; Tue, 27 Feb 2018 11:02:07 -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=D18S4rsl9/biMvAi6b8r6YEGkGJ0Lxe+F0wavkdzEoE=; b=faoCRJdczQkAT9VET1IogFzdo/8lpcQuKfTkNq+txZdUtytk89JfnAC7N8munbBXf3 PQySM2RPGwJjMl8kvBVPvZTz4UsBJuEmutiRCNKZlZfpw/xEiZ2wqKe6Iaa1qrzZVicY F5J5JDQ0P+bv4arirZCNm2vD3ch/3koewIXRA= 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=D18S4rsl9/biMvAi6b8r6YEGkGJ0Lxe+F0wavkdzEoE=; b=oXUxgblki6Y8ZmjWFsvJ8fQx0TjQ1ucSNBbWvzmvKWuPy9L1ebdcRm5MpycN1ofxU4 Qkbj68Lus2TpVeNEugfh9bJ/7Jyp7LFSPtA1GjJcy3EWtBGkaX1c/TNPTcX3lhraBDux rdxmffYH/eWLe51nSq6smlvtWlgSg7J54kxR4+pCE9xGNn7fwjAQkChIowLP3x+T2NLQ Qdgqr8I+rksKhDGR1Gei88+8uMmkJZriv7z3tFe5XOG5eyWCutiEErNMYpeOQMoRJfg5 PQeN4BR6adBsdBMQN2aYylCmdPzRzQiGOrNoMBRX8EDX8vkgj97beueVzu+cyYO383Sy zU7w== X-Gm-Message-State: APf1xPAizoeOs89E006L+pxbk6NgfyFy3XLjfhQR77j1jzQDJ29hRSOy sTmxOwN0bJIDIrVm4VmbJ7poodZJwtXcBkPiM/wcZQ== X-Google-Smtp-Source: AG47ELuZqku4Fn2jKVrEiMhXGct87vvocemfEeh5MWSafJLZNFvqWkucpLHyLYgGYT+n/ARC4tv33GfnIaTKIOcUC+k= X-Received: by 10.36.230.69 with SMTP id e66mr2196215ith.42.1519758126965; Tue, 27 Feb 2018 11:02:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.138.209 with HTTP; Tue, 27 Feb 2018 11:02:06 -0800 (PST) In-Reply-To: <20180227185801.6d7mgbkaqtxppcid@bivouac.eciton.net> References: <20180227175132.1607-1-ard.biesheuvel@linaro.org> <20180227183327.lg6juoabvbc3jute@bivouac.eciton.net> <20180227185801.6d7mgbkaqtxppcid@bivouac.eciton.net> From: Ard Biesheuvel Date: Tue, 27 Feb 2018 19:02:06 +0000 Message-ID: To: Leif Lindholm Cc: "edk2-devel@lists.01.org" , "Gao, Liming" , "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: Tue, 27 Feb 2018 18:56:01 -0000 Content-Type: text/plain; charset="UTF-8" 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. 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.