From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 918E52A5B for ; Mon, 23 Jan 2017 08:45:34 +0100 (CET) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP; 22 Jan 2017 23:45:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,273,1477983600"; d="scan'208";a="51485606" Received: from yliu-dev.sh.intel.com ([10.239.67.162]) by orsmga004.jf.intel.com with ESMTP; 22 Jan 2017 23:45:32 -0800 From: Yuanhan Liu To: Neil Horman Cc: Yuanhan Liu , Bruce Richardson , dpdk stable Date: Mon, 23 Jan 2017 15:46:36 +0800 Message-Id: <1485157675-32114-1-git-send-email-yuanhan.liu@linux.intel.com> X-Mailer: git-send-email 1.9.0 Subject: [dpdk-stable] patch 'pmdinfogen: fix endianness with cross-compilation' has been queued to stable release 16.11.1 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 07:45:35 -0000 Hi, FYI, your patch has been queued to stable release 16.11.1 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 01/28/17. So please shout if anyone has objections. --- Note 16.11 is a LTS release. v16.11.1 is planned to be released shortly (about 2-3 weeks) after v17.02. --- Thanks. --yliu --- >>From d21918d85abec753de382b664117258798a71d7c Mon Sep 17 00:00:00 2001 From: Neil Horman Date: Fri, 18 Nov 2016 13:47:52 -0500 Subject: [PATCH] pmdinfogen: fix endianness with cross-compilation [ upstream commit 112fc39b829039ee4ade210c464d26fecde7eac0 ] pmdinfogen has a bug in which, during build, it pulls in rte_byteorder.h to obtain the rte macros for byteswapping between the cpu byte order and big or little endian. Unfortunately, pmdinfogen is a tool that is only meant to be run during the build of dpdk components, and so, it runs on the host. In cross compile environments however, the rte_byteorder.h is configured using a target cpu, who's endianness may differ from that of the host, leading to improper swapping. The fix is to use host system defined byte swapping routines rather than the dpdk provided routines. Note that we are using non posix compliant routines, as the posix compliant api only addresses 16 and 32 bit swaps, and we also need 64 bit swaps. Those macros exist (via endian.h), but BSD and Linux put that header in different locations so some ifdeffery is required. Tested successfully by myself on Linux and BSD systems. Fixes: 98b0fdb0ffc6 ("pmdinfogen: add buildtools and pmdinfogen utility") Signed-off-by: Neil Horman Tested-by: Bruce Richardson --- buildtools/pmdinfogen/pmdinfogen.h | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/buildtools/pmdinfogen/pmdinfogen.h b/buildtools/pmdinfogen/pmdinfogen.h index 1da2966..e9eabff 100644 --- a/buildtools/pmdinfogen/pmdinfogen.h +++ b/buildtools/pmdinfogen/pmdinfogen.h @@ -16,12 +16,16 @@ #include #include #include +#ifdef __linux__ +#include +#else +#include +#endif #include #include #include #include #include -#include /* On BSD-alike OSes elf.h defines these according to host's word size */ #undef ELF_ST_BIND @@ -75,9 +79,9 @@ #define CONVERT_NATIVE(fend, width, x) ({ \ typeof(x) ___x; \ if ((fend) == ELFDATA2LSB) \ - ___x = rte_le_to_cpu_##width(x); \ + ___x = le##width##toh(x); \ else \ - ___x = rte_be_to_cpu_##width(x); \ + ___x = be##width##toh(x); \ ___x; \ }) -- 1.9.0