From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id C35AA475E; Tue, 15 Nov 2016 15:28:06 +0100 (CET) Received: from cpe-2606-a000-111b-40ed-7aac-c0ff-fec2-933b.dyn6.twc.com ([2606:a000:111b:40ed:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1c6eiN-0007NQ-FE; Tue, 15 Nov 2016 09:28:01 -0500 Date: Tue, 15 Nov 2016 09:27:50 -0500 From: Neil Horman To: Hemant Agrawal Cc: Jerin Jacob , "dev@dpdk.org" , "users@dpdk.org" , "Jacob, Jerin" , Jan Viktorin Message-ID: <20161115142750.GA11283@hmsreliant.think-freely.org> References: <20161113205924.GA11392@localhost.localdomain> <20161114144839.GA15570@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Score: -2.9 (--) X-Spam-Status: No 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: Tue, 15 Nov 2016 14:28:07 -0000 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