From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 01D371B13A for ; Wed, 10 Apr 2019 16:27:43 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2019 07:27:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,332,1549958400"; d="scan'208";a="133092530" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.35]) by orsmga008.jf.intel.com with SMTP; 10 Apr 2019 07:27:40 -0700 Received: by (sSMTP sendmail emulation); Wed, 10 Apr 2019 15:27:40 +0100 Date: Wed, 10 Apr 2019 15:27:39 +0100 From: Bruce Richardson To: Aaron Conole Cc: konstantin.ananyev@intel.com, dev@dpdk.org Message-ID: <20190410142739.GF718@bricha3-MOBL.ger.corp.intel.com> References: <20190410134517.63896-1-bruce.richardson@intel.com> <20190410134517.63896-3-bruce.richardson@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH 2/2] bpf: remove use of weak functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 14:27:44 -0000 On Wed, Apr 10, 2019 at 10:07:33AM -0400, Aaron Conole wrote: > Bruce Richardson writes: > > > Weak functions don't work well with static libraries and require the use of > > "whole-archive" flag to ensure that the correct function is used when > > linking. Since the weak function is only used as a placeholder within this > > library alone, we can replace it with a non-weak version protected using > > preprocessor ifdefs. > > > > Signed-off-by: Bruce Richardson > > --- > > I agree with dropping the weak implementations. > > But, can't we adjust the order of objects when building with multiple > strong definitions and the linker will choose the first? I know this > works for the GNU linker. > > I do find this information to help support this statement: > > https://stackoverflow.com/questions/51656838/attribute-weak-and-static-libraries > > Unfortunately, I don't find anything in the C standard to govern entity > precedence. This means it isn't something that works across linker > implementations (but compatible implementations like clang will maintain > that behavior). > It may be possible, but I'd be worried about the fragility of the support. Is it a good idea to have multiple implementations of a function in a .a file. Without running the resulting binary, we have no way of knowing the correct function was picked up. At least with the weak versions, we can see from nm what is used. /Bruce From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id A443CA0096 for ; Wed, 10 Apr 2019 16:27:45 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D9BBA1B184; Wed, 10 Apr 2019 16:27:44 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 01D371B13A for ; Wed, 10 Apr 2019 16:27:43 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2019 07:27:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,332,1549958400"; d="scan'208";a="133092530" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.35]) by orsmga008.jf.intel.com with SMTP; 10 Apr 2019 07:27:40 -0700 Received: by (sSMTP sendmail emulation); Wed, 10 Apr 2019 15:27:40 +0100 Date: Wed, 10 Apr 2019 15:27:39 +0100 From: Bruce Richardson To: Aaron Conole Cc: konstantin.ananyev@intel.com, dev@dpdk.org Message-ID: <20190410142739.GF718@bricha3-MOBL.ger.corp.intel.com> References: <20190410134517.63896-1-bruce.richardson@intel.com> <20190410134517.63896-3-bruce.richardson@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH 2/2] bpf: remove use of weak functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190410142739.ZSELb9jRZ250bSXrXsrlSRpy8Ixd0ojzKO5hXDnVg_I@z> On Wed, Apr 10, 2019 at 10:07:33AM -0400, Aaron Conole wrote: > Bruce Richardson writes: > > > Weak functions don't work well with static libraries and require the use of > > "whole-archive" flag to ensure that the correct function is used when > > linking. Since the weak function is only used as a placeholder within this > > library alone, we can replace it with a non-weak version protected using > > preprocessor ifdefs. > > > > Signed-off-by: Bruce Richardson > > --- > > I agree with dropping the weak implementations. > > But, can't we adjust the order of objects when building with multiple > strong definitions and the linker will choose the first? I know this > works for the GNU linker. > > I do find this information to help support this statement: > > https://stackoverflow.com/questions/51656838/attribute-weak-and-static-libraries > > Unfortunately, I don't find anything in the C standard to govern entity > precedence. This means it isn't something that works across linker > implementations (but compatible implementations like clang will maintain > that behavior). > It may be possible, but I'd be worried about the fragility of the support. Is it a good idea to have multiple implementations of a function in a .a file. Without running the resulting binary, we have no way of knowing the correct function was picked up. At least with the weak versions, we can see from nm what is used. /Bruce