From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wes1-so1.wedos.net (wes1-so1-b.wedos.net [46.28.106.43]) by dpdk.org (Postfix) with ESMTP id CDFA3D558; Fri, 11 Nov 2016 14:51:06 +0100 (CET) Received: from pcviktorin.fit.vutbr.cz (pcviktorin.fit.vutbr.cz [147.229.13.147]) by wes1-so1.wedos.net (Postfix) with ESMTPSA id 3tFhCG1Kkwz8RZ; Fri, 11 Nov 2016 14:51:06 +0100 (CET) Date: Fri, 11 Nov 2016 14:48:51 +0100 From: Jan Viktorin To: Hemant Agrawal Cc: Neil Horman , "dev@dpdk.org" , "users@dpdk.org" , "Jacob, Jerin" Message-ID: <20161111144851.3154a651@pcviktorin.fit.vutbr.cz> In-Reply-To: References: Organization: RehiveTech MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 13:51:07 -0000 Hello all, On Fri, 11 Nov 2016 10:34:39 +0000 Hemant Agrawal wrote: > Hi Neil, > Pmdinfogen compiles with host compiler. It usages rte_byte= order.h of the target platform. This seems wierd to me... why is it so? I couldn't find any usage of rte_by= teorder.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) tar= get binaries. Is that right? If the tool needs to know endianity then we probably need a header telling just the tar= get's endianity (or other metadata). > However, if the host compiler is older than 4.8, it will be an issue duri= ng 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-compi= les DPDK for Intel x86 (I admit that this is quite a ridiculous situation, so take it easy ;)). Then we have just opp= osite issues... Would we like to fill the DPDK x86 code base with #ifdef...#endif everytime there is some assembly co= de? I'd just like to point out that this single instruction is not the true source of the problem. It is like compla= ining that nasm cannot compile Thumb2 instructions... No it cannot, sorry. >=20 > /* fix missing __builtin_bswap16 for gcc older then 4.8 */ > #if !(__GNUC__ > 4 || (__GNUC__ =3D=3D 4 && __GNUC_MINOR__ >=3D 8)) > static inline uint16_t rte_arch_bswap16(uint16_t _x) > { > register uint16_t x =3D _x; > asm volatile ("rev16 %0,%1" > : "=3Dr" (x) > : "r" (x) > ); > return x; > } > #endif >=20 > One easy solution is that we add compiler platform check in this code sec= tion 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 =E2=80=A6. >=20 > 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 >=20 > Regards, > Hemant >=20 >=20 > From: Michael Wildt [mailto:michael.wildt@broadcom.com] > Sent: Wednesday, September 14, 2016 7:18 PM > To: Hemant Agrawal > Cc: Thomas Monjalon ; users@dpdk.org > Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vho= st and pmdinfogen issues >=20 > Hi Hemant, >=20 > Thanks for the pointer to the 4.9.3 version. Haven't had issues with 4.9.= 2 but good to know. >=20 > I gave that one a try and that works as well but as with the 5.3 I have t= o be on a Ubuntu not RHEL6 to make it work. >=20 > Thanks, > Michael >=20 > On Wed, Sep 14, 2016 at 3:25 AM, Hemant Agrawal > wrote: > Hi Michael, > One of the problem, I found with Linaro gcc 4.9 toolchain for i68= 6 (default one), that it seems to be built with older kernel headers (<3.8)= . This usages older linux/vhost.h file. >=20 > However, we have not observed this issue with x86_64 based toolchain on 6= 4 bit m/c. > https://releases.linaro.org/14.11/components/toolchain/binaries/aarch64-= linux-gnu/ >=20 > Regards, > Hemant >=20 > > -----Original Message----- > > From: users [mailto:users-bounces@dpdk.org] On Behalf Of Michael Wildt > > Sent: Wednesday, September 14, 2016 12:05 AM > > To: Thomas Monjalon > > > Cc: users@dpdk.org > > Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_v= host and > > pmdinfogen issues > > > > Hi Thomas, > > > > The Linaro gcc 4.9 is correct when it gets to __GNUC_MINOR__, used a te= st > > application. Its actually 4.9.2. > > > > Tried a newer Linaro tool chain, turned out to be a bit more complicate= d 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 > > =20 > > > wrote: =20 > > =20 > > > 2016-09-13 07:45, Michael Wildt: =20 > > > > Hi Thomas, > > > > > > > > Appreciate the assistance. Please see inline. > > > > > > > > > > > > On Tue, Sep 13, 2016 at 5:03 AM, Thomas Monjalon < =20 > > > thomas.monjalon@6wind.com> =20 > > > > wrote: > > > > =20 > > > > > Hi, > > > > > > > > > > 2016-09-12 22:20, Michael Wildt: =20 > > > > > > I'm attempting to cross compile DPDK on an x86 for an ARM64 tar= get. =20 > > > This =20 > > > > > > fails in the following areas, using latest dpdk as of 9/12. Whe= n =20 > > > > > compiling =20 > > > > > > natively there are no issues. =20 > > > > > > > > > > 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? > > > > > =20 > > > > > > > > Sure can. > > > > > > > > make config T=3Darm64-armv8a-linuxapp-gcc CROSS=3D/projects/ccxsw/ > > > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/ =20 > > > bin/aarch64-linux-gnu- =20 > > > > ARCH=3Darm64 > > > > > > > > make T=3Darm64-armv8a-linuxapp-gcc CROSS=3D/projects/ccxsw/ > > > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/ =20 > > > bin/aarch64-linux-gnu- =20 > > > > ARCH=3Darm64 RTE_KERNELDIR=3D/projects/kernel > > > > =20 > > > > > > - librte_vhost, fails with: > > > > > > > > > > > > /projects/dpdk_latest/lib/librte_vhost/vhost_user/virtio- =20 > > > > > net-user.c:250:23: =20 > > > > > > error: array subscript is above array bounds [-Werror=3Darray-b= ounds] > > > > > > rvq =3D dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_RXQ]; =20 > > > > > [...] =20 > > > > > > - buildtools/pmdinfogen, fails with: > > > > > > > > > > > > =3D=3D 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_ =20 > > > byteorder.h:53: =20 > > > > > > Error: no such instruction: `rev16 %bx,%bx' =20 > > > > > [...] =20 > > > > > > - 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 fai= ling. =20 > > > > > > 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__ =3D=3D 4 && __GNUC_MINOR__ >=3D 8)) > > > > > > I know you are using gcc-4.9 but maybe __GNUC_MINOR__ is wrong in you= rs. > > > > > > =20 >=20 --=20 Jan Viktorin E-mail: Viktorin@RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic