DPDK patches and discussions
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: dev@dpdk.org
Cc: Neil Horman <nhorman@tuxdriver.com>,
	Hemant Agrawal <hemant.agrawal@nxp.com>,
	Jerin Jacob <Jerin.Jacob@cavium.com>,
	Bruce Richardson <bruce.richardson@intel.com>,
	Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: [dpdk-dev] [PATCH] pmdinfogen: Fix pmdinfogen to select proper endianess on cross-compile
Date: Fri, 18 Nov 2016 13:47:52 -0500	[thread overview]
Message-ID: <1479494872-9302-1-git-send-email-nhorman@tuxdriver.com> (raw)

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 endianess 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.

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Hemant Agrawal <hemant.agrawal@nxp.com>
CC: Jerin Jacob <Jerin.Jacob@cavium.com>
CC: Bruce Richardson <bruce.richardson@intel.com>
CC: Thomas Monjalon <thomas.monjalon@6wind.com>
---
 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..7c787c1 100644
--- a/buildtools/pmdinfogen/pmdinfogen.h
+++ b/buildtools/pmdinfogen/pmdinfogen.h
@@ -16,12 +16,16 @@
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <sys/mman.h>
+#ifdef __linux__ 
+#include <endian.h>
+#else
+#include <sys/endian.h>
+#endif
 #include <fcntl.h>
 #include <unistd.h>
 #include <elf.h>
 #include <rte_config.h>
 #include <rte_pci.h>
-#include <rte_byteorder.h>
 
 /* 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; \
 })
 
-- 
2.7.4

             reply	other threads:[~2016-11-18 18:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-18 18:47 Neil Horman [this message]
2016-11-21 10:11 ` Bruce Richardson
2016-12-01 15:17   ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1479494872-9302-1-git-send-email-nhorman@tuxdriver.com \
    --to=nhorman@tuxdriver.com \
    --cc=Jerin.Jacob@cavium.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=thomas.monjalon@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).