From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com [209.85.215.51]) by dpdk.org (Postfix) with ESMTP id 1988637A4 for ; Thu, 14 Jul 2016 17:43:47 +0200 (CEST) Received: by mail-lf0-f51.google.com with SMTP id q132so67332013lfe.3 for ; Thu, 14 Jul 2016 08:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=VNbOSgKea7kWZV02ZHEPvTop+HPAca06pUhhv4QvqXI=; b=LeD4lWQiavVv4w6zEUxLOAUWZHdMjOXl9nCcQ6xjLe4s8A1TyjxDPJiyYi2K7tS/jA j2h+Z1z9PcbTB2JM/piCQiawnW0vshBF9BMoxVT+jSHGrBu/SgqyQC/q/QSmgMvoLIQ2 znY9YmsHMnBiEcNisElto+XZzY9uUUcS62B74= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=VNbOSgKea7kWZV02ZHEPvTop+HPAca06pUhhv4QvqXI=; b=kT4eSHICONDdnrApRcAWOrvo7LON9TDR4/2WQuA3hoi6TWzvy5y+tperUKxb63BxJx dEKpBBg7qA4DKfBW/QRlzE4OXMmRWiYuXKQ74ooVrFvOukT2mAWQ8p0ZD9WQzioccvBZ 279b8wQxfI2ZUvoC/1mIUbap6/2T+PbeX8MoGdssPzR/+/2kU1HnaLz5iLBUKVyv1mSu Nsi/r0WSn7lDaAnLVZ8FswB+oa6od9TSLX7/pzm4eDFBLVKoDhNMUQdlGcuArXeTMZ3d 2IhxiaIkw9NifG/qZnGjLtNaVnr77/guZVPoftwT3LXu4/DFh5z7aaVrTO0pN40H3J8g 7Rcw== X-Gm-Message-State: ALyK8tKW5+F7mdlMw4JiaQN5EAch/3Fo9dvHMSErN4NOhbxNP919YfkK85j4cnnN73xASwCC X-Received: by 10.25.20.69 with SMTP id k66mr6836879lfi.35.1468511026700; Thu, 14 Jul 2016 08:43:46 -0700 (PDT) Received: from [172.18.45.108] ([195.11.233.227]) by smtp.googlemail.com with ESMTPSA id 35sm908424ljb.10.2016.07.14.08.43.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jul 2016 08:43:45 -0700 (PDT) To: Sergio Gonzalez Monroy , "Elo, Matias (Nokia - FI/Espoo)" , "dev@dpdk.org" References: <3745bde4-f539-21d4-51e4-369d35697e57@intel.com> <555e6907-e7df-5856-50d5-bca5c4d27909@intel.com> Cc: "ferruh.yigit@intel.com" , "damarion@cisco.com" From: Zoltan Kiss Message-ID: <5787B331.5010503@linaro.org> Date: Thu, 14 Jul 2016 16:43:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <555e6907-e7df-5856-50d5-bca5c4d27909@intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] weak functions in some drivers 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: Thu, 14 Jul 2016 15:43:47 -0000 Hi, On 01/07/16 11:19, Sergio Gonzalez Monroy wrote: > On 01/07/2016 11:16, Elo, Matias (Nokia - FI/Espoo) wrote: >>> -----Original Message----- >>> From: Sergio Gonzalez Monroy [mailto:sergio.gonzalez.monroy@intel.com] >>> Sent: Friday, July 01, 2016 1:05 PM >>> To: Elo, Matias (Nokia - FI/Espoo) ; >>> dev@dpdk.org >>> Cc: ferruh.yigit@intel.com; damarion@cisco.com >>> Subject: Re: [dpdk-dev] weak functions in some drivers >>> >>> On 01/07/2016 10:42, Elo, Matias (Nokia - FI/Espoo) wrote: >>>>>>>>> What is not clear to me is motivation to use weak here instead >>>>>>>>> of simply >>>>>> using >CONFIG_RTE_I40E_INC_VECTOR >>>>>>>>> macro to exclude stubs in i40e_rxtx.c. It will make library >>>>>>>>> smaller and >>> avoid >>>>>> issues like this one >>>>>>>>> which are quite hard to troubleshoot. >>>>>>>> Since this issue seen in fd.io, I didn't investigated more, but >>>>>>>> I don't >>>>>>>> want to clock your valid question, this is an attempt to >>>>>>>> resurrect the >>>>>>>> question ... >>>>>>> Hi, >>>>>>> >>>>>>> We are having exactly the same problem. For us the aforementioned >>>>>> workaround doesn't seem to work and vector mode is always disabled >>>>>> with >>> the >>>>>> i40e drivers. If I modify i40e_rxtx.c and exclude the stub >>>>>> functions using >>>>>> CONFIG_RTE_I40E_INC_VECTOR everything works as expected. >>>>>>> We are building DPDK with the CONFIG_RTE_BUILD_COMBINE_LIBS option >>>>>> enabled and link DPDK library to our application. >>>>>>> Any other ideas how this could be fixed? >>>>>>> >>>>>>> Regards, >>>>>>> Matias >>>>>>> >>>>>> So you have tried to link a combined static lib with --whole-archive >>>>>> -ldpdk --no-whole-archive and still get the wrong/weak function >>>>>> definition? >>>>>> >>>>>> Sergio >>>>> I actually just managed to fix the problem. In our case I had to add >>>>> '-Wl,--whole-archive,-ldpdk,--no-whole-archive' to the end of >>>>> AM_LDFLAGS. >>>>> >>>> It turned out that the problem actually wasn't fixed. >>>> >>>> DPDK is built with CONFIG_RTE_BUILD_COMBINE_LIBS=y and >>> EXTRA_CFLAGS="-fPIC" >>>> What we are linking originally: >>>> -l:libdpdk.a >>>> >>>> This works otherwise but vector mode i40e is not enabled. >>>> >>>> When trying: >>>> -Wl,--whole-archive,-l:libdpdk.a,--no-whole-archive >>>> >>>> Linking fails with ' undefined reference' errors to several dpdk >>>> functions >>> (rte_eal_init, rte_cpu_get_flag_enabled, rte_eth_stats_get...). >>>> Btw. there seems to be a Stack Overflow question related to this: >>> http://stackoverflow.com/questions/38064021/dpdk-include-libraries-in-dpdk- >>> >>> application-compiled-as-shared-library >>>> -Matias >>> What DPDK version are you using? >> v16.04 > > Ok. I was asking because there is no CONFIG_RTE_BUILD_COMBINE_LIBS in > 16.04. > > > Could you provide full link/compile command line? I'm not able to > reproduce the issue so far I've dug into this issue a bit, let me explain it with some example code: main.c: void bar(void); void foo(void); int main() { bar(); //foo(); } ====================================== weak.c: #include void __attribute__((weak)) foo(void) { printf("Weak\n"); } void bar(void) { foo(); printf("No call\n"); } ====================================== strong.c: #include void foo(void) { printf("Strong\n"); } Compile the second two into a library and link it with main: gcc -o strong.o -c strong.c ar rcs libbar.a strong.o weak.o gcc main.c -L. -lbar -o main Then look which foo were used: objdump -x libbar.a | grep foo 0000000000000000 g F .text 0000000000000010 foo 0000000000000000 w F .text 0000000000000010 foo 0000000000000015 R_X86_64_PC32 foo-0x0000000000000004 objdump -x main | grep foo 0000000000400538 w F .text 0000000000000010 foo So it got the weak version, simply because bar() was referred, and that already pulled the other symbols from that .o file, so ld stop looking for the another ones. If you uncomment the foo() call in main(), it will do a proper search, and pulls in the strong symbol. I think there are only workarounds here: - use --whole-archive, but that pulls in a lot of stuff you don't necessarily need. And if you feed that stuff to libtool, it seems to misbehave when it sees the -Wl parameter. The Ubuntu 14.04 libtool definitely has a bug around that. Matias ran into this with ODP-DPDK: it fixed the weak symbol problem in the .so, but then libtool forgot to add -ldpdk when doing statical linking - use only dynamic linking: I guess that's not a viable restriction The best would be to get rid of these weak functions, as they don't work the same with dynamic and static linking, especially the latter is problematic. I think Damjan suggested something like that in his original message. I propose something like this: @@ -3268,10 +3268,40 @@ i40e_set_tx_function(struct rte_eth_dev *dev) } /* Stubs needed for linkage when CONFIG_RTE_I40E_INC_VECTOR is set to 'n' */ -int __attribute__((weak)) +int __attribute__((cold)) i40e_rx_vec_dev_conf_condition_check(struct rte_eth_dev __rte_unused *dev) { +#ifndef RTE_LIBRTE_I40E_INC_VECTOR return -1; +#else [stuff from the vector version] +#endif /* (RTE_I40E_INC_VECTOR == n) */ } And then get rid of the vector version of this function. How about that? And of course this applies to all weak functions. Regards, Zoltan