[dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[Hemant Agrawal]

Hi Neil,
               Pmdinfogen compiles with host compiler. It usages rte_byteorder.h of the target platform.
However, if the host compiler is older than 4.8, it will be an issue during cross compilation for some platforms.
e.g. if we are compiling on x86 host for ARM, x86 host compiler will not understand the arm asm instructions.

/* fix missing __builtin_bswap16 for gcc older then 4.8 */
#if !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
static inline uint16_t rte_arch_bswap16(uint16_t _x)
{
               register uint16_t x = _x;
               asm volatile ("rev16 %0,%1"
                                    : "=r" (x)
                                    : "r" (x)
                                    );
               return x;
}
#endif

One easy solution is that we add compiler platform check in this code section of rte_byteorder.h
e.g
#if !(defined __arm__ || defined __aarch64__)
static inline uint16_t rte_arch_bswap16(uint16_t _x)
{
               return (_x >> 8) | ((_x << 8) & 0xff00);
}
#else ….

Is there a better way to fix it?

Regards,
Hemant


From: Michael Wildt [mailto:michael.wildt@broadcom.com]
Sent: Wednesday, September 14, 2016 7:18 PM
To: Hemant Agrawal <hemant.agrawal@nxp.com>
Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; users@dpdk.org
Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost and pmdinfogen issues

Hi Hemant,

Thanks for the pointer to the 4.9.3 version. Haven't had issues with 4.9.2 but good to know.

I gave that one a try and that works as well but as with the 5.3 I have to be on a Ubuntu not RHEL6 to make it work.

Thanks,
Michael

On Wed, Sep 14, 2016 at 3:25 AM, Hemant Agrawal <hemant.agrawal@nxp.com<mailto:hemant.agrawal@nxp.com>> wrote:
Hi Michael,
        One of the problem, I found with Linaro gcc 4.9 toolchain for i686 (default one), that it seems to be built with older kernel headers (<3.8). This usages older linux/vhost.h file.

However, we have not observed this issue with x86_64 based toolchain on 64 bit m/c.
 https://releases.linaro.org/14.11/components/toolchain/binaries/aarch64-linux-gnu/

Regards,
Hemant

> -----Original Message-----
> From: users [mailto:users-bounces@dpdk.org<mailto:users-bounces@dpdk.org>] On Behalf Of Michael Wildt
> Sent: Wednesday, September 14, 2016 12:05 AM
> To: Thomas Monjalon <thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>>
> Cc: users@dpdk.org<mailto:users@dpdk.org>
> Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost and
> pmdinfogen issues
>
> Hi Thomas,
>
> The Linaro gcc 4.9 is correct when it gets to __GNUC_MINOR__, used a test
> application. Its actually 4.9.2.
>
> Tried a newer Linaro tool chain, turned out to be a bit more complicated since
> that does not work on RHEL6, is however a success. With Linaro 5.3 one can
> cross compile dpdk fine with no errors, though the rte_byteorder.h file still
> points to arm's version, but pmdinfogen builds.
>
> Probably should still fix both issues just to keep the base clean.
>
> At least I have a workaround in the interim.
>
> Thanks for the help.
>
> Thanks,
> Michael
>
>
> On Tue, Sep 13, 2016 at 11:07 AM, Thomas Monjalon
> <thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>
> > wrote:
>
> > 2016-09-13 07:45, Michael Wildt:
> > > Hi Thomas,
> > >
> > > Appreciate the assistance. Please see inline.
> > >
> > >
> > > On Tue, Sep 13, 2016 at 5:03 AM, Thomas Monjalon <
> > thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > 2016-09-12 22:20, Michael Wildt:
> > > > > I'm attempting to cross compile DPDK on an x86 for an ARM64 target.
> > This
> > > > > fails in the following areas, using latest dpdk as of 9/12. When
> > > > compiling
> > > > > natively there are no issues.
> > > >
> > > > Your analysis below seems good.
> > > > Interestingly, I do not see such error (don't know why).
> > > > Please could you share the commands you are using?
> > > >
> > >
> > > Sure can.
> > >
> > > make config T=arm64-armv8a-linuxapp-gcc CROSS=/projects/ccxsw/
> > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/
> > bin/aarch64-linux-gnu-
> > > ARCH=arm64
> > >
> > > make T=arm64-armv8a-linuxapp-gcc CROSS=/projects/ccxsw/
> > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/
> > bin/aarch64-linux-gnu-
> > > ARCH=arm64 RTE_KERNELDIR=/projects/kernel
> > >
> > > > > - librte_vhost, fails with:
> > > > >
> > > > > /projects/dpdk_latest/lib/librte_vhost/vhost_user/virtio-
> > > > net-user.c:250:23:
> > > > > error: array subscript is above array bounds [-Werror=array-bounds]
> > > > >    rvq = dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_RXQ];
> > > > [...]
> > > > > - buildtools/pmdinfogen, fails with:
> > > > >
> > > > > == Build buildtools/pmdinfogen
> > > > >   HOSTCC pmdinfogen.o
> > > > > /projects/dpdk_test_wget/dpdk-16.07/build/include/rte_byteorder.h:
> > > > > Assembler messages:
> > > > > /projects/dpdk_test_wget/dpdk-16.07/build/include/rte_
> > byteorder.h:53:
> > > > > Error: no such instruction: `rev16 %bx,%bx'
> > > > [...]
> > > > >   - The issue is due to the rte_byteorder.h file which gets
> > > > >   symlink'ed with the ARM version at the beginning of the build.
> > > > >   The pmdinfogen is always compiled for x86 thus the asm is failing.
> >
> > It is definitely something to fix.
> > In the meantime, you should be able to compile DPDK by using a more
> > recent toolchain. This error is in:
> >
> > /* fix missing __builtin_bswap16 for gcc older then 4.8 */ #if
> > !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> >
> > I know you are using gcc-4.9 but maybe __GNUC_MINOR__ is wrong in yours.
> >
> >

Re: [dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[Jan Viktorin]

Hello all,

On Fri, 11 Nov 2016 10:34:39 +0000
Hemant Agrawal <hemant.agrawal@nxp.com> wrote:

> Hi Neil,
>                Pmdinfogen compiles with host compiler. It usages rte_byteorder.h of the target platform.

This seems wierd to me... why is it so? I couldn't find any usage of rte_byteorder.h in the source of pmdinfogen
(what am I missing?). Why is it included there?

The pmdinfogen executes on the host but works with the (cross-compiled) target binaries. Is that right? If the tool
needs to know endianity then we probably need a header telling just the target's endianity (or other metadata).

> However, if the host compiler is older than 4.8, it will be an issue during cross compilation for some platforms.
> e.g. if we are compiling on x86 host for ARM, x86 host compiler will not understand the arm asm instructions.

This is not the actual issue. Consider an ARM build server that cross-compiles DPDK for Intel x86 (I admit that this
is quite a ridiculous situation, so take it easy ;)). Then we have just opposite issues... Would we like to fill the
DPDK x86 code base with #ifdef...#endif everytime there is some assembly code? I'd just like to point out that this
single instruction is not the true source of the problem. It is like complaining that nasm cannot compile Thumb2
instructions... No it cannot, sorry.

> 
> /* fix missing __builtin_bswap16 for gcc older then 4.8 */
> #if !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> static inline uint16_t rte_arch_bswap16(uint16_t _x)
> {
>                register uint16_t x = _x;
>                asm volatile ("rev16 %0,%1"
>                                     : "=r" (x)
>                                     : "r" (x)
>                                     );
>                return x;
> }
> #endif
> 
> One easy solution is that we add compiler platform check in this code section of rte_byteorder.h
> e.g
> #if !(defined __arm__ || defined __aarch64__)
> static inline uint16_t rte_arch_bswap16(uint16_t _x)
> {
>                return (_x >> 8) | ((_x << 8) & 0xff00);
> }
> #else ….
> 
> Is there a better way to fix it?

In my opinion, this would work as a hotfix but not as a solution.

Kind regards
Jan

> 
> Regards,
> Hemant
> 
> 
> From: Michael Wildt [mailto:michael.wildt@broadcom.com]
> Sent: Wednesday, September 14, 2016 7:18 PM
> To: Hemant Agrawal <hemant.agrawal@nxp.com>
> Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; users@dpdk.org
> Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost and pmdinfogen issues
> 
> Hi Hemant,
> 
> Thanks for the pointer to the 4.9.3 version. Haven't had issues with 4.9.2 but good to know.
> 
> I gave that one a try and that works as well but as with the 5.3 I have to be on a Ubuntu not RHEL6 to make it work.
> 
> Thanks,
> Michael
> 
> On Wed, Sep 14, 2016 at 3:25 AM, Hemant Agrawal <hemant.agrawal@nxp.com<mailto:hemant.agrawal@nxp.com>> wrote:
> Hi Michael,
>         One of the problem, I found with Linaro gcc 4.9 toolchain for i686 (default one), that it seems to be built with older kernel headers (<3.8). This usages older linux/vhost.h file.
> 
> However, we have not observed this issue with x86_64 based toolchain on 64 bit m/c.
>  https://releases.linaro.org/14.11/components/toolchain/binaries/aarch64-linux-gnu/
> 
> Regards,
> Hemant
> 
> > -----Original Message-----
> > From: users [mailto:users-bounces@dpdk.org<mailto:users-bounces@dpdk.org>] On Behalf Of Michael Wildt
> > Sent: Wednesday, September 14, 2016 12:05 AM
> > To: Thomas Monjalon <thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>>
> > Cc: users@dpdk.org<mailto:users@dpdk.org>
> > Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost and
> > pmdinfogen issues
> >
> > Hi Thomas,
> >
> > The Linaro gcc 4.9 is correct when it gets to __GNUC_MINOR__, used a test
> > application. Its actually 4.9.2.
> >
> > Tried a newer Linaro tool chain, turned out to be a bit more complicated since
> > that does not work on RHEL6, is however a success. With Linaro 5.3 one can
> > cross compile dpdk fine with no errors, though the rte_byteorder.h file still
> > points to arm's version, but pmdinfogen builds.
> >
> > Probably should still fix both issues just to keep the base clean.
> >
> > At least I have a workaround in the interim.
> >
> > Thanks for the help.
> >
> > Thanks,
> > Michael
> >
> >
> > On Tue, Sep 13, 2016 at 11:07 AM, Thomas Monjalon
> > <thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>  
> > > wrote:  
> >  
> > > 2016-09-13 07:45, Michael Wildt:  
> > > > Hi Thomas,
> > > >
> > > > Appreciate the assistance. Please see inline.
> > > >
> > > >
> > > > On Tue, Sep 13, 2016 at 5:03 AM, Thomas Monjalon <  
> > > thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>>  
> > > > wrote:
> > > >  
> > > > > Hi,
> > > > >
> > > > > 2016-09-12 22:20, Michael Wildt:  
> > > > > > I'm attempting to cross compile DPDK on an x86 for an ARM64 target.  
> > > This  
> > > > > > fails in the following areas, using latest dpdk as of 9/12. When  
> > > > > compiling  
> > > > > > natively there are no issues.  
> > > > >
> > > > > Your analysis below seems good.
> > > > > Interestingly, I do not see such error (don't know why).
> > > > > Please could you share the commands you are using?
> > > > >  
> > > >
> > > > Sure can.
> > > >
> > > > make config T=arm64-armv8a-linuxapp-gcc CROSS=/projects/ccxsw/
> > > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/  
> > > bin/aarch64-linux-gnu-  
> > > > ARCH=arm64
> > > >
> > > > make T=arm64-armv8a-linuxapp-gcc CROSS=/projects/ccxsw/
> > > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/  
> > > bin/aarch64-linux-gnu-  
> > > > ARCH=arm64 RTE_KERNELDIR=/projects/kernel
> > > >  
> > > > > > - librte_vhost, fails with:
> > > > > >
> > > > > > /projects/dpdk_latest/lib/librte_vhost/vhost_user/virtio-  
> > > > > net-user.c:250:23:  
> > > > > > error: array subscript is above array bounds [-Werror=array-bounds]
> > > > > >    rvq = dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_RXQ];  
> > > > > [...]  
> > > > > > - buildtools/pmdinfogen, fails with:
> > > > > >
> > > > > > == Build buildtools/pmdinfogen
> > > > > >   HOSTCC pmdinfogen.o
> > > > > > /projects/dpdk_test_wget/dpdk-16.07/build/include/rte_byteorder.h:
> > > > > > Assembler messages:
> > > > > > /projects/dpdk_test_wget/dpdk-16.07/build/include/rte_  
> > > byteorder.h:53:  
> > > > > > Error: no such instruction: `rev16 %bx,%bx'  
> > > > > [...]  
> > > > > >   - The issue is due to the rte_byteorder.h file which gets
> > > > > >   symlink'ed with the ARM version at the beginning of the build.
> > > > > >   The pmdinfogen is always compiled for x86 thus the asm is failing.  
> > >
> > > It is definitely something to fix.
> > > In the meantime, you should be able to compile DPDK by using a more
> > > recent toolchain. This error is in:
> > >
> > > /* fix missing __builtin_bswap16 for gcc older then 4.8 */ #if
> > > !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> > >
> > > I know you are using gcc-4.9 but maybe __GNUC_MINOR__ is wrong in yours.
> > >
> > >  
> 



-- 
   Jan Viktorin                  E-mail: Viktorin@RehiveTech.com
   System Architect              Web:    www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

Re: [dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[Neil Horman]

On Fri, Nov 11, 2016 at 02:48:51PM +0100, Jan Viktorin wrote:
> Hello all,
> 
> On Fri, 11 Nov 2016 10:34:39 +0000
> Hemant Agrawal <hemant.agrawal@nxp.com> wrote:
> 
> > Hi Neil,
> >                Pmdinfogen compiles with host compiler. It usages rte_byteorder.h of the target platform.
> 
> This seems wierd to me... why is it so? I couldn't find any usage of rte_byteorder.h in the source of pmdinfogen
> (what am I missing?). Why is it included there?
> 
See the CONVERT_NATIVE macro in pmdinfogen.h.  It makes use of the various
rte_[le|be]_to_cpu macros from rte_byteorder.h

> The pmdinfogen executes on the host but works with the (cross-compiled) target binaries. Is that right? If the tool
> needs to know endianity then we probably need a header telling just the target's endianity (or other metadata).
> 
pmdinfogen works on ELF object files, and can extract the endianess from the ELF
header itself (using the e_ident[EI_DATA] area).

> > However, if the host compiler is older than 4.8, it will be an issue during cross compilation for some platforms.
> > e.g. if we are compiling on x86 host for ARM, x86 host compiler will not understand the arm asm instructions.
> 
> This is not the actual issue. Consider an ARM build server that cross-compiles DPDK for Intel x86 (I admit that this
> is quite a ridiculous situation, so take it easy ;)). Then we have just opposite issues... Would we like to fill the
> DPDK x86 code base with #ifdef...#endif everytime there is some assembly code? I'd just like to point out that this
> single instruction is not the true source of the problem. It is like complaining that nasm cannot compile Thumb2
> instructions... No it cannot, sorry.
> 
It sounds like the issue is a general 'how to get support for another arch'
question.  In the case of rte_byteorder.h, its actually pretty cut and dry,
because thankfully all the instructions are wrapped up into nice C inline
functions or macros.  The trick is to simply define the api instructions in the
file for each arch, with a default generic case that just uses C, so it can be
compiled into whatever the target arch needs (although it may run more slowly).
That gets you initial support, and then you can optimize be creating a special
case for the new arch.  You have to do that for every API set that has per-arch
optimizations (the atomic ops, the tsc ops, memcpy, cpuflags, prefetch, etc).
Its time consuming, but its just the way it is.

> > 
> > /* fix missing __builtin_bswap16 for gcc older then 4.8 */
> > #if !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> > static inline uint16_t rte_arch_bswap16(uint16_t _x)
> > {
> >                register uint16_t x = _x;
> >                asm volatile ("rev16 %0,%1"
> >                                     : "=r" (x)
> >                                     : "r" (x)
> >                                     );
> >                return x;
> > }
> > #endif
> > 
> > One easy solution is that we add compiler platform check in this code section of rte_byteorder.h
> > e.g
> > #if !(defined __arm__ || defined __aarch64__)
> > static inline uint16_t rte_arch_bswap16(uint16_t _x)
> > {
> >                return (_x >> 8) | ((_x << 8) & 0xff00);
> > }
> > #else ….
> > 
> > Is there a better way to fix it?
> 
Well, almost, what you have above is a good solution, but it shouldn't be the
ARM solution, it should be the code used if an arch specific variant of the code
isn't defined. The pattern rte_byteorder should follow is

#if (defined i686 || defined x86_64)
	<x86 specific implementation of rte_arch_bswap16>
#elif (defined ppc || ppc64)
	<ppc specific implementation of rte_arch_bswap16>
#else
	<generic implementation of rte_arch_bswap16>
#endif

The idea is to have a generic version that works for any arch to fall back on,
then if you have a faster way to do it on your arch, you can add a clause at
your leisure to do so.

Neil

> In my opinion, this would work as a hotfix but not as a solution.
> 
> Kind regards
> Jan
> 
> > 
> > Regards,
> > Hemant
> > 
> > 
> > From: Michael Wildt [mailto:michael.wildt@broadcom.com]
> > Sent: Wednesday, September 14, 2016 7:18 PM
> > To: Hemant Agrawal <hemant.agrawal@nxp.com>
> > Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; users@dpdk.org
> > Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost and pmdinfogen issues
> > 
> > Hi Hemant,
> > 
> > Thanks for the pointer to the 4.9.3 version. Haven't had issues with 4.9.2 but good to know.
> > 
> > I gave that one a try and that works as well but as with the 5.3 I have to be on a Ubuntu not RHEL6 to make it work.
> > 
> > Thanks,
> > Michael
> > 
> > On Wed, Sep 14, 2016 at 3:25 AM, Hemant Agrawal <hemant.agrawal@nxp.com<mailto:hemant.agrawal@nxp.com>> wrote:
> > Hi Michael,
> >         One of the problem, I found with Linaro gcc 4.9 toolchain for i686 (default one), that it seems to be built with older kernel headers (<3.8). This usages older linux/vhost.h file.
> > 
> > However, we have not observed this issue with x86_64 based toolchain on 64 bit m/c.
> >  https://releases.linaro.org/14.11/components/toolchain/binaries/aarch64-linux-gnu/
> > 
> > Regards,
> > Hemant
> > 
> > > -----Original Message-----
> > > From: users [mailto:users-bounces@dpdk.org<mailto:users-bounces@dpdk.org>] On Behalf Of Michael Wildt
> > > Sent: Wednesday, September 14, 2016 12:05 AM
> > > To: Thomas Monjalon <thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>>
> > > Cc: users@dpdk.org<mailto:users@dpdk.org>
> > > Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost and
> > > pmdinfogen issues
> > >
> > > Hi Thomas,
> > >
> > > The Linaro gcc 4.9 is correct when it gets to __GNUC_MINOR__, used a test
> > > application. Its actually 4.9.2.
> > >
> > > Tried a newer Linaro tool chain, turned out to be a bit more complicated since
> > > that does not work on RHEL6, is however a success. With Linaro 5.3 one can
> > > cross compile dpdk fine with no errors, though the rte_byteorder.h file still
> > > points to arm's version, but pmdinfogen builds.
> > >
> > > Probably should still fix both issues just to keep the base clean.
> > >
> > > At least I have a workaround in the interim.
> > >
> > > Thanks for the help.
> > >
> > > Thanks,
> > > Michael
> > >
> > >
> > > On Tue, Sep 13, 2016 at 11:07 AM, Thomas Monjalon
> > > <thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>  
> > > > wrote:  
> > >  
> > > > 2016-09-13 07:45, Michael Wildt:  
> > > > > Hi Thomas,
> > > > >
> > > > > Appreciate the assistance. Please see inline.
> > > > >
> > > > >
> > > > > On Tue, Sep 13, 2016 at 5:03 AM, Thomas Monjalon <  
> > > > thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>>  
> > > > > wrote:
> > > > >  
> > > > > > Hi,
> > > > > >
> > > > > > 2016-09-12 22:20, Michael Wildt:  
> > > > > > > I'm attempting to cross compile DPDK on an x86 for an ARM64 target.  
> > > > This  
> > > > > > > fails in the following areas, using latest dpdk as of 9/12. When  
> > > > > > compiling  
> > > > > > > natively there are no issues.  
> > > > > >
> > > > > > Your analysis below seems good.
> > > > > > Interestingly, I do not see such error (don't know why).
> > > > > > Please could you share the commands you are using?
> > > > > >  
> > > > >
> > > > > Sure can.
> > > > >
> > > > > make config T=arm64-armv8a-linuxapp-gcc CROSS=/projects/ccxsw/
> > > > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/  
> > > > bin/aarch64-linux-gnu-  
> > > > > ARCH=arm64
> > > > >
> > > > > make T=arm64-armv8a-linuxapp-gcc CROSS=/projects/ccxsw/
> > > > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/  
> > > > bin/aarch64-linux-gnu-  
> > > > > ARCH=arm64 RTE_KERNELDIR=/projects/kernel
> > > > >  
> > > > > > > - librte_vhost, fails with:
> > > > > > >
> > > > > > > /projects/dpdk_latest/lib/librte_vhost/vhost_user/virtio-  
> > > > > > net-user.c:250:23:  
> > > > > > > error: array subscript is above array bounds [-Werror=array-bounds]
> > > > > > >    rvq = dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_RXQ];  
> > > > > > [...]  
> > > > > > > - buildtools/pmdinfogen, fails with:
> > > > > > >
> > > > > > > == Build buildtools/pmdinfogen
> > > > > > >   HOSTCC pmdinfogen.o
> > > > > > > /projects/dpdk_test_wget/dpdk-16.07/build/include/rte_byteorder.h:
> > > > > > > Assembler messages:
> > > > > > > /projects/dpdk_test_wget/dpdk-16.07/build/include/rte_  
> > > > byteorder.h:53:  
> > > > > > > Error: no such instruction: `rev16 %bx,%bx'  
> > > > > > [...]  
> > > > > > >   - The issue is due to the rte_byteorder.h file which gets
> > > > > > >   symlink'ed with the ARM version at the beginning of the build.
> > > > > > >   The pmdinfogen is always compiled for x86 thus the asm is failing.  
> > > >
> > > > It is definitely something to fix.
> > > > In the meantime, you should be able to compile DPDK by using a more
> > > > recent toolchain. This error is in:
> > > >
> > > > /* fix missing __builtin_bswap16 for gcc older then 4.8 */ #if
> > > > !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> > > >
> > > > I know you are using gcc-4.9 but maybe __GNUC_MINOR__ is wrong in yours.
> > > >
> > > >  
> > 
> 
> 
> 
> -- 
>    Jan Viktorin                  E-mail: Viktorin@RehiveTech.com
>    System Architect              Web:    www.RehiveTech.com
>    RehiveTech
>    Brno, Czech Republic
> 

Re: [dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[Jerin Jacob]

On Fri, Nov 11, 2016 at 10:34:39AM +0000, Hemant Agrawal wrote:
> Hi Neil,
>                Pmdinfogen compiles with host compiler. It usages rte_byteorder.h of the target platform.
> However, if the host compiler is older than 4.8, it will be an issue during cross compilation for some platforms.
> e.g. if we are compiling on x86 host for ARM, x86 host compiler will not understand the arm asm instructions.
> 
> /* fix missing __builtin_bswap16 for gcc older then 4.8 */
> #if !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> static inline uint16_t rte_arch_bswap16(uint16_t _x)
> {
>                register uint16_t x = _x;
>                asm volatile ("rev16 %0,%1"
>                                     : "=r" (x)
>                                     : "r" (x)
>                                     );
>                return x;
> }
> #endif
> 
> One easy solution is that we add compiler platform check in this code section of rte_byteorder.h
> e.g
> #if !(defined __arm__ || defined __aarch64__)
> static inline uint16_t rte_arch_bswap16(uint16_t _x)
> {
>                return (_x >> 8) | ((_x << 8) & 0xff00);
> }
> #else ….
> 
> Is there a better way to fix it?

IMO, It is a HOST build infrastructure issue. If a host app is using the
dpdk service then it should compile and link against HOST target(in this
specific case, build/x86_64-native-linuxapp-gcc). I think, introducing the
HOSTTARGET kind of scheme is a clean solution.

/Jerin

Re: [dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[Neil Horman]

On Mon, Nov 14, 2016 at 02:29:24AM +0530, Jerin Jacob wrote:
> On Fri, Nov 11, 2016 at 10:34:39AM +0000, Hemant Agrawal wrote:
> > Hi Neil,
> >                Pmdinfogen compiles with host compiler. It usages rte_byteorder.h of the target platform.
> > However, if the host compiler is older than 4.8, it will be an issue during cross compilation for some platforms.
> > e.g. if we are compiling on x86 host for ARM, x86 host compiler will not understand the arm asm instructions.
> > 
> > /* fix missing __builtin_bswap16 for gcc older then 4.8 */
> > #if !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> > static inline uint16_t rte_arch_bswap16(uint16_t _x)
> > {
> >                register uint16_t x = _x;
> >                asm volatile ("rev16 %0,%1"
> >                                     : "=r" (x)
> >                                     : "r" (x)
> >                                     );
> >                return x;
> > }
> > #endif
> > 
> > One easy solution is that we add compiler platform check in this code section of rte_byteorder.h
> > e.g
> > #if !(defined __arm__ || defined __aarch64__)
> > static inline uint16_t rte_arch_bswap16(uint16_t _x)
> > {
> >                return (_x >> 8) | ((_x << 8) & 0xff00);
> > }
> > #else ….
> > 
> > Is there a better way to fix it?
> 
> IMO, It is a HOST build infrastructure issue. If a host app is using the
> dpdk service then it should compile and link against HOST target(in this
> specific case, build/x86_64-native-linuxapp-gcc). I think, introducing the
> HOSTTARGET kind of scheme is a clean solution.
> 
> /Jerin
> 
> 
That would be accurate.  That is to say, pmdinfogen is a tool that should only
be run on the host doing the build, by the host doing the build, and so should
be compiled to run on the host, not on the target being built for.

Yeah, so what we need is a way to get to the host version of rte_byteorder.h
when building in a cross environment

Neil

Re: [dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[Hemant Agrawal]

> On Mon, Nov 14, 2016 at 02:29:24AM +0530, Jerin Jacob wrote:
> > On Fri, Nov 11, 2016 at 10:34:39AM +0000, Hemant Agrawal wrote:
> > > Hi Neil,
> > >                Pmdinfogen compiles with host compiler. It usages rte_byteorder.h
> of the target platform.
> > > However, if the host compiler is older than 4.8, it will be an issue during cross
> compilation for some platforms.
> > > e.g. if we are compiling on x86 host for ARM, x86 host compiler will not
> understand the arm asm instructions.
> > >
> > > /* fix missing __builtin_bswap16 for gcc older then 4.8 */ #if
> > > !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)) static
> > > inline uint16_t rte_arch_bswap16(uint16_t _x) {
> > >                register uint16_t x = _x;
> > >                asm volatile ("rev16 %0,%1"
> > >                                     : "=r" (x)
> > >                                     : "r" (x)
> > >                                     );
> > >                return x;
> > > }
> > > #endif
> > >
> > > One easy solution is that we add compiler platform check in this
> > > code section of rte_byteorder.h e.g #if !(defined __arm__ || defined
> > > __aarch64__) static inline uint16_t rte_arch_bswap16(uint16_t _x) {
> > >                return (_x >> 8) | ((_x << 8) & 0xff00); } #else ….
> > >
> > > Is there a better way to fix it?
> >
> > IMO, It is a HOST build infrastructure issue. If a host app is using
> > the dpdk service then it should compile and link against HOST
> > target(in this specific case, build/x86_64-native-linuxapp-gcc). I
> > think, introducing the HOSTTARGET kind of scheme is a clean solution.
> >
> > /Jerin
> >
> >
> That would be accurate.  That is to say, pmdinfogen is a tool that should only be
> run on the host doing the build, by the host doing the build, and so should be
> compiled to run on the host, not on the target being built for.
> 
> Yeah, so what we need is a way to get to the host version of rte_byteorder.h
> when building in a cross environment
> 
+1 

> Neil

Re: [dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[Neil Horman]

On Tue, Nov 15, 2016 at 09:34:16AM +0000, Hemant Agrawal wrote:
> > On Mon, Nov 14, 2016 at 02:29:24AM +0530, Jerin Jacob wrote:
> > > On Fri, Nov 11, 2016 at 10:34:39AM +0000, Hemant Agrawal wrote:
> > > > Hi Neil,
> > > >                Pmdinfogen compiles with host compiler. It usages rte_byteorder.h
> > of the target platform.
> > > > However, if the host compiler is older than 4.8, it will be an issue during cross
> > compilation for some platforms.
> > > > e.g. if we are compiling on x86 host for ARM, x86 host compiler will not
> > understand the arm asm instructions.
> > > >
> > > > /* fix missing __builtin_bswap16 for gcc older then 4.8 */ #if
> > > > !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)) static
> > > > inline uint16_t rte_arch_bswap16(uint16_t _x) {
> > > >                register uint16_t x = _x;
> > > >                asm volatile ("rev16 %0,%1"
> > > >                                     : "=r" (x)
> > > >                                     : "r" (x)
> > > >                                     );
> > > >                return x;
> > > > }
> > > > #endif
> > > >
> > > > One easy solution is that we add compiler platform check in this
> > > > code section of rte_byteorder.h e.g #if !(defined __arm__ || defined
> > > > __aarch64__) static inline uint16_t rte_arch_bswap16(uint16_t _x) {
> > > >                return (_x >> 8) | ((_x << 8) & 0xff00); } #else ….
> > > >
> > > > Is there a better way to fix it?
> > >
> > > IMO, It is a HOST build infrastructure issue. If a host app is using
> > > the dpdk service then it should compile and link against HOST
> > > target(in this specific case, build/x86_64-native-linuxapp-gcc). I
> > > think, introducing the HOSTTARGET kind of scheme is a clean solution.
> > >
> > > /Jerin
> > >
> > >
> > That would be accurate.  That is to say, pmdinfogen is a tool that should only be
> > run on the host doing the build, by the host doing the build, and so should be
> > compiled to run on the host, not on the target being built for.
> > 
> > Yeah, so what we need is a way to get to the host version of rte_byteorder.h
> > when building in a cross environment
> > 
> +1 
> 
> > Neil
> 
Actually, looking at this, I think we're 90% there anyway.  The buildtools
already uses the hostapp.mk file (as it should), to target the host build
system, rather than any cross target, so we're good there.  The only question
is, should we be using rte_byteorder.h at all, and I think the answer is no, we
shouldn't.  I assert that because the byteorder file is configured for the
target, not the host, and so we shouldn't be touching it at all.  Instead we
should just be using the posix htobe*/htole*/letoh*/betoh* variants to do the
endian conversion, as those are always configured to work on the local build
host.


I'll propose a patch shortly for you to test.
Neil

Re: [dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[Neil Horman]

On Tue, Nov 15, 2016 at 09:34:16AM +0000, Hemant Agrawal wrote:
> > On Mon, Nov 14, 2016 at 02:29:24AM +0530, Jerin Jacob wrote:
> > > On Fri, Nov 11, 2016 at 10:34:39AM +0000, Hemant Agrawal wrote:
> > > > Hi Neil,
> > > >                Pmdinfogen compiles with host compiler. It usages rte_byteorder.h
> > of the target platform.
> > > > However, if the host compiler is older than 4.8, it will be an issue during cross
> > compilation for some platforms.
> > > > e.g. if we are compiling on x86 host for ARM, x86 host compiler will not
> > understand the arm asm instructions.
> > > >
> > > > /* fix missing __builtin_bswap16 for gcc older then 4.8 */ #if
> > > > !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)) static
> > > > inline uint16_t rte_arch_bswap16(uint16_t _x) {
> > > >                register uint16_t x = _x;
> > > >                asm volatile ("rev16 %0,%1"
> > > >                                     : "=r" (x)
> > > >                                     : "r" (x)
> > > >                                     );
> > > >                return x;
> > > > }
> > > > #endif
> > > >
> > > > One easy solution is that we add compiler platform check in this
> > > > code section of rte_byteorder.h e.g #if !(defined __arm__ || defined
> > > > __aarch64__) static inline uint16_t rte_arch_bswap16(uint16_t _x) {
> > > >                return (_x >> 8) | ((_x << 8) & 0xff00); } #else ….
> > > >
> > > > Is there a better way to fix it?
> > >
> > > IMO, It is a HOST build infrastructure issue. If a host app is using
> > > the dpdk service then it should compile and link against HOST
> > > target(in this specific case, build/x86_64-native-linuxapp-gcc). I
> > > think, introducing the HOSTTARGET kind of scheme is a clean solution.
> > >
> > > /Jerin
> > >
> > >
> > That would be accurate.  That is to say, pmdinfogen is a tool that should only be
> > run on the host doing the build, by the host doing the build, and so should be
> > compiled to run on the host, not on the target being built for.
> > 
> > Yeah, so what we need is a way to get to the host version of rte_byteorder.h
> > when building in a cross environment
> > 
> +1 
> 
> > Neil
> 

Give this a try, I've tested it on linux, but not BSD.  From what I read the
functions are not posix compliant, though they should exist on all BSD and Linux
systems in recent history.  There may be some fiddling needed for Net and
OpenBSD variants, but I think this is the right general direction.


diff --git a/buildtools/pmdinfogen/pmdinfogen.h b/buildtools/pmdinfogen/pmdinfogen.h
index 1da2966..c5ef89d 100644
--- a/buildtools/pmdinfogen/pmdinfogen.h
+++ b/buildtools/pmdinfogen/pmdinfogen.h
@@ -21,7 +21,6 @@
 #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 +74,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; \
 })
 

Re: [dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[Thomas Monjalon]

2016-11-15 09:27, Neil Horman:
> On Tue, Nov 15, 2016 at 09:34:16AM +0000, Hemant Agrawal wrote:
> > > > On Fri, Nov 11, 2016 at 10:34:39AM +0000, Hemant Agrawal wrote:
> > > > > Hi Neil,
> > > > >    Pmdinfogen compiles with host compiler. It usages rte_byteorder.h
> > > > >    of the target platform.
[...]
> > > Yeah, so what we need is a way to get to the host version of rte_byteorder.h
> > > when building in a cross environment
> > > 
> > +1 
> > 
> Actually, looking at this, I think we're 90% there anyway.  The buildtools
> already uses the hostapp.mk file (as it should), to target the host build
> system, rather than any cross target, so we're good there.  The only question
> is, should we be using rte_byteorder.h at all, and I think the answer is no, we
> shouldn't.  I assert that because the byteorder file is configured for the
> target, not the host, and so we shouldn't be touching it at all.  Instead we
> should just be using the posix htobe*/htole*/letoh*/betoh* variants to do the
> endian conversion, as those are always configured to work on the local build
> host.

Yes there are 2 possible fixes:
- get a host version of EAL
- do not use EAL for host applications

As Neil, I think there is no point in using EAL for a host application.

Re: [dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[Hemant Agrawal]

> -----Original Message-----
> From: Neil Horman [mailto:nhorman@tuxdriver.com]
> On Tue, Nov 15, 2016 at 09:34:16AM +0000, Hemant Agrawal wrote:
> > > On Mon, Nov 14, 2016 at 02:29:24AM +0530, Jerin Jacob wrote:
> > > > On Fri, Nov 11, 2016 at 10:34:39AM +0000, Hemant Agrawal wrote:
> > > > > Hi Neil,
> > > > >                Pmdinfogen compiles with host compiler. It usages
> rte_byteorder.h
> > > of the target platform.
> > > > > However, if the host compiler is older than 4.8, it will be an issue during
> cross
> > > compilation for some platforms.
> > > > > e.g. if we are compiling on x86 host for ARM, x86 host compiler will not
> > > understand the arm asm instructions.
> > > > >
> > > > > /* fix missing __builtin_bswap16 for gcc older then 4.8 */ #if
> > > > > !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)) static
> > > > > inline uint16_t rte_arch_bswap16(uint16_t _x) {
> > > > >                register uint16_t x = _x;
> > > > >                asm volatile ("rev16 %0,%1"
> > > > >                                     : "=r" (x)
> > > > >                                     : "r" (x)
> > > > >                                     );
> > > > >                return x;
> > > > > }
> > > > > #endif
> > > > >
> > > > > One easy solution is that we add compiler platform check in this
> > > > > code section of rte_byteorder.h e.g #if !(defined __arm__ || defined
> > > > > __aarch64__) static inline uint16_t rte_arch_bswap16(uint16_t _x) {
> > > > >                return (_x >> 8) | ((_x << 8) & 0xff00); } #else ….
> > > > >
> > > > > Is there a better way to fix it?
> > > >
> > > > IMO, It is a HOST build infrastructure issue. If a host app is using
> > > > the dpdk service then it should compile and link against HOST
> > > > target(in this specific case, build/x86_64-native-linuxapp-gcc). I
> > > > think, introducing the HOSTTARGET kind of scheme is a clean solution.
> > > >
> > > > /Jerin
> > > >
> > > >
> > > That would be accurate.  That is to say, pmdinfogen is a tool that should only
> be
> > > run on the host doing the build, by the host doing the build, and so should be
> > > compiled to run on the host, not on the target being built for.
> > >
> > > Yeah, so what we need is a way to get to the host version of rte_byteorder.h
> > > when building in a cross environment
> > >
> > +1
> >
> > > Neil
> >
> 
> Give this a try, I've tested it on linux, but not BSD.  From what I read the
> functions are not posix compliant, though they should exist on all BSD and Linux
> systems in recent history.  There may be some fiddling needed for Net and
> OpenBSD variants, but I think this is the right general direction.

+ 1
This patch works good for Linux. 

> 
> 
> diff --git a/buildtools/pmdinfogen/pmdinfogen.h
> b/buildtools/pmdinfogen/pmdinfogen.h
> index 1da2966..c5ef89d 100644
> --- a/buildtools/pmdinfogen/pmdinfogen.h
> +++ b/buildtools/pmdinfogen/pmdinfogen.h
> @@ -21,7 +21,6 @@
>  #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 +74,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; \
>  })
> 

Re: [dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[Neil Horman]

On Fri, Nov 18, 2016 at 12:03:19PM +0000, Hemant Agrawal wrote:
> > -----Original Message-----
> > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > On Tue, Nov 15, 2016 at 09:34:16AM +0000, Hemant Agrawal wrote:
> > > > On Mon, Nov 14, 2016 at 02:29:24AM +0530, Jerin Jacob wrote:
> > > > > On Fri, Nov 11, 2016 at 10:34:39AM +0000, Hemant Agrawal wrote:
> > > > > > Hi Neil,
> > > > > >                Pmdinfogen compiles with host compiler. It usages
> > rte_byteorder.h
> > > > of the target platform.
> > > > > > However, if the host compiler is older than 4.8, it will be an issue during
> > cross
> > > > compilation for some platforms.
> > > > > > e.g. if we are compiling on x86 host for ARM, x86 host compiler will not
> > > > understand the arm asm instructions.
> > > > > >
> > > > > > /* fix missing __builtin_bswap16 for gcc older then 4.8 */ #if
> > > > > > !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)) static
> > > > > > inline uint16_t rte_arch_bswap16(uint16_t _x) {
> > > > > >                register uint16_t x = _x;
> > > > > >                asm volatile ("rev16 %0,%1"
> > > > > >                                     : "=r" (x)
> > > > > >                                     : "r" (x)
> > > > > >                                     );
> > > > > >                return x;
> > > > > > }
> > > > > > #endif
> > > > > >
> > > > > > One easy solution is that we add compiler platform check in this
> > > > > > code section of rte_byteorder.h e.g #if !(defined __arm__ || defined
> > > > > > __aarch64__) static inline uint16_t rte_arch_bswap16(uint16_t _x) {
> > > > > >                return (_x >> 8) | ((_x << 8) & 0xff00); } #else ….
> > > > > >
> > > > > > Is there a better way to fix it?
> > > > >
> > > > > IMO, It is a HOST build infrastructure issue. If a host app is using
> > > > > the dpdk service then it should compile and link against HOST
> > > > > target(in this specific case, build/x86_64-native-linuxapp-gcc). I
> > > > > think, introducing the HOSTTARGET kind of scheme is a clean solution.
> > > > >
> > > > > /Jerin
> > > > >
> > > > >
> > > > That would be accurate.  That is to say, pmdinfogen is a tool that should only
> > be
> > > > run on the host doing the build, by the host doing the build, and so should be
> > > > compiled to run on the host, not on the target being built for.
> > > >
> > > > Yeah, so what we need is a way to get to the host version of rte_byteorder.h
> > > > when building in a cross environment
> > > >
> > > +1
> > >
> > > > Neil
> > >
> > 
> > Give this a try, I've tested it on linux, but not BSD.  From what I read the
> > functions are not posix compliant, though they should exist on all BSD and Linux
> > systems in recent history.  There may be some fiddling needed for Net and
> > OpenBSD variants, but I think this is the right general direction.
> 
> + 1
> This patch works good for Linux. 
> 
Can someone test it on BSD?  I'd like to ensure we don't need to modify it for
that platform

Neil

> > 
> > 
> > diff --git a/buildtools/pmdinfogen/pmdinfogen.h
> > b/buildtools/pmdinfogen/pmdinfogen.h
> > index 1da2966..c5ef89d 100644
> > --- a/buildtools/pmdinfogen/pmdinfogen.h
> > +++ b/buildtools/pmdinfogen/pmdinfogen.h
> > @@ -21,7 +21,6 @@
> >  #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 +74,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; \
> >  })
> > 

Re: [dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[Bruce Richardson]

On Fri, Nov 18, 2016 at 08:50:52AM -0500, Neil Horman wrote:
> On Fri, Nov 18, 2016 at 12:03:19PM +0000, Hemant Agrawal wrote:
> > > -----Original Message-----
> > > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > > On Tue, Nov 15, 2016 at 09:34:16AM +0000, Hemant Agrawal wrote:
> > > > > On Mon, Nov 14, 2016 at 02:29:24AM +0530, Jerin Jacob wrote:
> > > > > > On Fri, Nov 11, 2016 at 10:34:39AM +0000, Hemant Agrawal wrote:
> > > > > > > Hi Neil,
> > > > > > >                Pmdinfogen compiles with host compiler. It usages
> > > rte_byteorder.h
> > > > > of the target platform.
> > > > > > > However, if the host compiler is older than 4.8, it will be an issue during
> > > cross
> > > > > compilation for some platforms.
> > > > > > > e.g. if we are compiling on x86 host for ARM, x86 host compiler will not
> > > > > understand the arm asm instructions.
> > > > > > >
> > > > > > > /* fix missing __builtin_bswap16 for gcc older then 4.8 */ #if
> > > > > > > !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)) static
> > > > > > > inline uint16_t rte_arch_bswap16(uint16_t _x) {
> > > > > > >                register uint16_t x = _x;
> > > > > > >                asm volatile ("rev16 %0,%1"
> > > > > > >                                     : "=r" (x)
> > > > > > >                                     : "r" (x)
> > > > > > >                                     );
> > > > > > >                return x;
> > > > > > > }
> > > > > > > #endif
> > > > > > >
> > > > > > > One easy solution is that we add compiler platform check in this
> > > > > > > code section of rte_byteorder.h e.g #if !(defined __arm__ || defined
> > > > > > > __aarch64__) static inline uint16_t rte_arch_bswap16(uint16_t _x) {
> > > > > > >                return (_x >> 8) | ((_x << 8) & 0xff00); } #else ….
> > > > > > >
> > > > > > > Is there a better way to fix it?
> > > > > >
> > > > > > IMO, It is a HOST build infrastructure issue. If a host app is using
> > > > > > the dpdk service then it should compile and link against HOST
> > > > > > target(in this specific case, build/x86_64-native-linuxapp-gcc). I
> > > > > > think, introducing the HOSTTARGET kind of scheme is a clean solution.
> > > > > >
> > > > > > /Jerin
> > > > > >
> > > > > >
> > > > > That would be accurate.  That is to say, pmdinfogen is a tool that should only
> > > be
> > > > > run on the host doing the build, by the host doing the build, and so should be
> > > > > compiled to run on the host, not on the target being built for.
> > > > >
> > > > > Yeah, so what we need is a way to get to the host version of rte_byteorder.h
> > > > > when building in a cross environment
> > > > >
> > > > +1
> > > >
> > > > > Neil
> > > >
> > > 
> > > Give this a try, I've tested it on linux, but not BSD.  From what I read the
> > > functions are not posix compliant, though they should exist on all BSD and Linux
> > > systems in recent history.  There may be some fiddling needed for Net and
> > > OpenBSD variants, but I think this is the right general direction.
> > 
> > + 1
> > This patch works good for Linux. 
> > 
> Can someone test it on BSD?  I'd like to ensure we don't need to modify it for
> that platform
> 
> Neil
> 
> > > 
> > > 
> > > diff --git a/buildtools/pmdinfogen/pmdinfogen.h
> > > b/buildtools/pmdinfogen/pmdinfogen.h
> > > index 1da2966..c5ef89d 100644
> > > --- a/buildtools/pmdinfogen/pmdinfogen.h
> > > +++ b/buildtools/pmdinfogen/pmdinfogen.h
> > > @@ -21,7 +21,6 @@
> > >  #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 +74,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; \
> > >  })
> > > 

For compile on FreeBSD 10 we need "#include <sys/endian.h>" and this
works.

/Bruce

Re: [dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[Neil Horman]

On Fri, Nov 18, 2016 at 04:37:38PM +0000, Bruce Richardson wrote:
> On Fri, Nov 18, 2016 at 08:50:52AM -0500, Neil Horman wrote:
> > On Fri, Nov 18, 2016 at 12:03:19PM +0000, Hemant Agrawal wrote:
> > > > -----Original Message-----
> > > > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > > > On Tue, Nov 15, 2016 at 09:34:16AM +0000, Hemant Agrawal wrote:
> > > > > > On Mon, Nov 14, 2016 at 02:29:24AM +0530, Jerin Jacob wrote:
> > > > > > > On Fri, Nov 11, 2016 at 10:34:39AM +0000, Hemant Agrawal wrote:
> > > > > > > > Hi Neil,
> > > > > > > >                Pmdinfogen compiles with host compiler. It usages
> > > > rte_byteorder.h
> > > > > > of the target platform.
> > > > > > > > However, if the host compiler is older than 4.8, it will be an issue during
> > > > cross
> > > > > > compilation for some platforms.
> > > > > > > > e.g. if we are compiling on x86 host for ARM, x86 host compiler will not
> > > > > > understand the arm asm instructions.
> > > > > > > >
> > > > > > > > /* fix missing __builtin_bswap16 for gcc older then 4.8 */ #if
> > > > > > > > !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)) static
> > > > > > > > inline uint16_t rte_arch_bswap16(uint16_t _x) {
> > > > > > > >                register uint16_t x = _x;
> > > > > > > >                asm volatile ("rev16 %0,%1"
> > > > > > > >                                     : "=r" (x)
> > > > > > > >                                     : "r" (x)
> > > > > > > >                                     );
> > > > > > > >                return x;
> > > > > > > > }
> > > > > > > > #endif
> > > > > > > >
> > > > > > > > One easy solution is that we add compiler platform check in this
> > > > > > > > code section of rte_byteorder.h e.g #if !(defined __arm__ || defined
> > > > > > > > __aarch64__) static inline uint16_t rte_arch_bswap16(uint16_t _x) {
> > > > > > > >                return (_x >> 8) | ((_x << 8) & 0xff00); } #else ….
> > > > > > > >
> > > > > > > > Is there a better way to fix it?
> > > > > > >
> > > > > > > IMO, It is a HOST build infrastructure issue. If a host app is using
> > > > > > > the dpdk service then it should compile and link against HOST
> > > > > > > target(in this specific case, build/x86_64-native-linuxapp-gcc). I
> > > > > > > think, introducing the HOSTTARGET kind of scheme is a clean solution.
> > > > > > >
> > > > > > > /Jerin
> > > > > > >
> > > > > > >
> > > > > > That would be accurate.  That is to say, pmdinfogen is a tool that should only
> > > > be
> > > > > > run on the host doing the build, by the host doing the build, and so should be
> > > > > > compiled to run on the host, not on the target being built for.
> > > > > >
> > > > > > Yeah, so what we need is a way to get to the host version of rte_byteorder.h
> > > > > > when building in a cross environment
> > > > > >
> > > > > +1
> > > > >
> > > > > > Neil
> > > > >
> > > > 
> > > > Give this a try, I've tested it on linux, but not BSD.  From what I read the
> > > > functions are not posix compliant, though they should exist on all BSD and Linux
> > > > systems in recent history.  There may be some fiddling needed for Net and
> > > > OpenBSD variants, but I think this is the right general direction.
> > > 
> > > + 1
> > > This patch works good for Linux. 
> > > 
> > Can someone test it on BSD?  I'd like to ensure we don't need to modify it for
> > that platform
> > 
> > Neil
> > 
> > > > 
> > > > 
> > > > diff --git a/buildtools/pmdinfogen/pmdinfogen.h
> > > > b/buildtools/pmdinfogen/pmdinfogen.h
> > > > index 1da2966..c5ef89d 100644
> > > > --- a/buildtools/pmdinfogen/pmdinfogen.h
> > > > +++ b/buildtools/pmdinfogen/pmdinfogen.h
> > > > @@ -21,7 +21,6 @@
> > > >  #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 +74,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; \
> > > >  })
> > > > 
> 
> For compile on FreeBSD 10 we need "#include <sys/endian.h>" and this
> works.
> 
Yeah, but that will break linux, because there endian.h is in the base include
directory.  I'll have to do some ifdeffing

Neil

> /Bruce
>