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 4B6F9A0576; Sat, 14 Mar 2020 00:38:31 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 956821BFBF; Sat, 14 Mar 2020 00:38:30 +0100 (CET) Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by dpdk.org (Postfix) with ESMTP id A207B1BFA5 for ; Sat, 14 Mar 2020 00:38:29 +0100 (CET) Received: by mail-lj1-f193.google.com with SMTP id r7so12417125ljp.10 for ; Fri, 13 Mar 2020 16:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=2kS8VH5mJYCyfjiuwe4VDt4yCzXyqnP9izjVaYdtsaY=; b=OxckFtjAWoI0aJ3VEbZ1gMlpzkLdiHgNXE7y+YvuU8E/Nl75lrOy96WpnnFi+f3xSQ N4JjG6G/oUcDtX9bGq/wTgk/q4phlF3VPEJ+R0t5jv5oSgtKMfFtJZ1F1K1cThpeR+8A JtLR6UqCK+Gwhs9NnGvdCoeOz/WzO1ZX8Y0lwcxzMxikFiDvdf8n7bfxDJORqygpyJmk hYcFtV+1Zrd/gY99hcGQumNINRFf6ku60GmKI5x4YSjung4qvPws0jorZTOEPkrgcWwR 0oSKiKD+UZziA0DvZs1WWZ6h12ItmeQaMliw524+bA7R6uZ0LfkjM4z7aHhOYZh99yap wl4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=2kS8VH5mJYCyfjiuwe4VDt4yCzXyqnP9izjVaYdtsaY=; b=e1OIM+lEmBZG1gkrPW65cu5jC4JpZd5kvbb8I6PPjcFc3qE2h7/+aKKjr7s+XuyOST SgK3ZSye3JuRwgjL+7tbid2/4vjRAeV0cQhIL+UZiS+V8gMVi0YH8PU/RsJOvDxqUfdt SNEKJb0fsPrljYDEdJO5wnzwP9KZCrVeZLYfiGTbBCsq+NooETR3XByoxU0oPPlEIS5q dS1/5txvW/Rk8dTXGQGWgbqqWnFc2UbETg5ofghH4dyjO8wwvWqM0ymk7R9qe50AWxbh 27Ma4Wl72GmnRDPyPFzYbvGlzhHivcWnIU4FgZMFpF9udULmXwl3funSiJNSct6pvyYP PQtg== X-Gm-Message-State: ANhLgQ3pjhkuPyVprQwE+Vj2juNPTupPh81mmdGYztI0tcLlfV8gV63B BCSrELrwbTc0BlQQtMA1Ddm5+Bvy X-Google-Smtp-Source: ADFU+vvcDU7ylhKJmJPX/xTvPY4WZ7E+t4BHr79V8uwUlD5gm6s7we3+PKG0/FnesqIXhhq7jPNQvw== X-Received: by 2002:a2e:87c5:: with SMTP id v5mr2994223ljj.166.1584142708895; Fri, 13 Mar 2020 16:38:28 -0700 (PDT) Received: from Sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id r4sm19550142lfc.40.2020.03.13.16.38.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Mar 2020 16:38:27 -0700 (PDT) Date: Sat, 14 Mar 2020 02:38:26 +0300 From: Dmitry Kozlyuk To: Thomas Monjalon Cc: dev@dpdk.org, Olivier Matz Message-ID: <20200314023826.699ab6c0@Sovereign> In-Reply-To: <3094952.KgjxqYA5nG@xps> References: <20200218000229.86621-1-dmitry.kozliuk@gmail.com> <20200227042537.187459-1-dmitry.kozliuk@gmail.com> <20200227042537.187459-2-dmitry.kozliuk@gmail.com> <3094952.KgjxqYA5nG@xps> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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" > 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? 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. 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). -- Dmitry Kozlyuk