From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 05AE1A0564; Sun, 15 Mar 2020 09:36:19 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1020A25D9; Sun, 15 Mar 2020 09:36:19 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 5B9CB1AFF for ; Sun, 15 Mar 2020 09:36:17 +0100 (CET) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A87C221F83; Sun, 15 Mar 2020 04:36:16 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Sun, 15 Mar 2020 04:36:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=9VOZgbe/ZXGJqNRJhru+eLHpKEZMxHPi2QuQeQGi1+E=; b=h+j6EOHT+itW EcFj/bkI+u3wLADrIbkuAlZT+vGRuzuOzgSLjmhmMp5U6aMsuN4B+jOEuMdWXJrg VtpoNtqoHf46dVRIGPdLJ0Y30uCE1aJTja1ERPE6u3/YAUN2CZuAzGR9B2+ADVED fRueYGC2mqf3x1KNkM3yxlpCFp+Xwbo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=9VOZgbe/ZXGJqNRJhru+eLHpKEZMxHPi2QuQeQGi1 +E=; b=Y3u700Z2I3TOyd2P+d+Mog9D5uAG69of0lbp6AOr/6rvXCRrPftCOiQXK CIESHC2Iy1n6Gxwcci+DanL7zFcrGewo+oc2MqajajEWc+wvxXMAejNszwp1i32S vnXFtCWUoT8qLxqUXeQ/4yWFEllpal39zbR2oAZadQVIBAWCmqgsWpb3x2HQiLhF kgofxyabQla7KJJwu5P/x9QKyMJMrwvjmACm4lj+WLliR/OBFOtEtiC1VZQarKZr 7591fsmEQlQx5oGImTsPuqX6nAKy3yeeUGY3l/93R7i2a4OpNKP4TCtLk/0+jd/M ReHbH5XzkTUPfNiqcMN/yEkt214Bg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeftddgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc fkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id A418C3280060; Sun, 15 Mar 2020 04:36:15 -0400 (EDT) From: Thomas Monjalon To: Dmitry Kozlyuk Cc: dev@dpdk.org, Olivier Matz Date: Sun, 15 Mar 2020 09:36:11 +0100 Message-ID: <15686856.Ash8RoxBsO@xps> In-Reply-To: <20200314023826.699ab6c0@Sovereign> References: <20200218000229.86621-1-dmitry.kozliuk@gmail.com> <3094952.KgjxqYA5nG@xps> <20200314023826.699ab6c0@Sovereign> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v4 1/7] eal: introduce portable format attribute X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 14/03/2020 00:38, Dmitry Kozlyuk: > > I suggest this change (I can send a patch fixing the issue in other .h files): > > > > +/* > > + * RTE_TOOLCHAIN_GCC is true if the target is built with GCC, > > + * while a host application (like pmdinfogen) may have another compiler. > > + * RTE_CC_IS_GNU is true if the file is compiled with GCC, > > + * no matter it is a target or host application. > > + */ > > +#if defined __GNUC__ && !defined __clang__ && !defined __INTEL_COMPILER > > +#define RTE_CC_IS_GNU > > +#endif > > + > > +#ifdef RTE_CC_IS_GNU > > -/** Define GCC_VERSION **/ > > -#ifdef RTE_TOOLCHAIN_GCC > > #define GCC_VERSION (__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + \ > > __GNUC_PATCHLEVEL__) > > #endif > > @@ -96,7 +105,7 @@ typedef uint16_t unaligned_uint16_t; > > * even if the underlying stdio implementation is ANSI-compliant, > > * so this must be overridden. > > */ > > -#if defined(RTE_TOOLCHAIN_GCC) > > +#ifdef RTE_CC_IS_GNU > > #define __rte_format_printf(format_index, first_arg) \ > > __attribute__((format(gnu_printf, format_index, first_arg))) > > #else > > The code you propose LGTM itself. If you think it's a better solution than > the one proposed below, I see no problem going with it. > > What I wonder is whether pmdinfogen should include the problematic code in the > first place. The errors come from declarations in rte_debug.h, but pmdinfogen > really can't use them, because definitions are compiled for different > machine. Pmdinfogen pulls rte_debug.h via rte_pci.h, which is only needed for > struct rte_pci_id. Shouldn't we instead break this bogus dependency chain by > moving struct rte_pci_id to a separate header? Splitting headers to avoid EAL dependency looks to be a bad precedent to me. > EAL defines are tied to the target toolchain and are consistent with each > other, from this point of view RTE_CC_IS_GNU looks like a workaround. Yes there are some target-arch-dependent code in EAL. But a host application is not supposed to use arch-dependent code. > Another > reason why pmdinfogen should not depend on EAL is that its code will differ > considerably for POSIX and Windows (ELF vs COFF, mmap vs Win32 API). I believe managing some OS differences should be helped with EAL.