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 787FDC492 for ; Mon, 29 Jun 2015 15:44:21 +0200 (CEST) Received: from voip-107-15-76-160.kyn.rr.com ([107.15.76.160] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Z9ZM8-0006sH-16; Mon, 29 Jun 2015 09:44:20 -0400 Date: Mon, 29 Jun 2015 09:44:15 -0400 From: Neil Horman To: Thomas Monjalon Message-ID: <20150629134415.GB2177@hmsreliant.think-freely.org> References: <1435088014-18973-1-git-send-email-nhorman@tuxdriver.com> <3172025.YLFsvjgh6J@xps13> <20150626143005.GA27458@hmsreliant.think-freely.org> <2152455.CiuiDMrZSi@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2152455.CiuiDMrZSi@xps13> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCHv3 2/3] rte_compat: Add MAP_STATIC_SYMBOL macro 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: Mon, 29 Jun 2015 13:44:21 -0000 On Sun, Jun 28, 2015 at 10:13:31PM +0200, Thomas Monjalon wrote: > 2015-06-26 10:30, Neil Horman: > > On Fri, Jun 26, 2015 at 02:52:50PM +0200, Thomas Monjalon wrote: > > > 2015-06-25 10:35, Neil Horman: > > > > +/* > > > > + * MAP_STATIC_SYMBOL > > > > + * If a function has been bifurcated into multiple versions, none of which > > > > + * are defined as the exported symbol name in the map file, this macro can be > > > > + * used to alias a specific version of the symbol to its exported name. For > > > > + * example, if you have 2 versions of a function foo_v1 and foo_v2, where the > > > > + * former is mapped to foo@DPDK_1 and the latter is mapped to foo@DPDK_2 when > > > > + * building a shared library, this macro can be used to map either foo_v1 or > > > > + * foo_v2 to the symbol foo when building a static library, e.g.: > > > > + * MAP_STATIC_SYMBOL(void foo(), foo_v2); > > > > + */ > > > > +#define MAP_STATIC_SYMBOL(f, p) > > > > + > > > > #else > > > > /* > > > > * No symbol versioning in use > > > > @@ -104,7 +105,7 @@ > > > > #define __vsym > > > > #define BASE_SYMBOL(b, n) > > > > #define BIND_DEFAULT_SYMBOL(b, e, n) > > > > - > > > > +#define MAP_STATIC_SYMBOL(f, p) f __attribute__((alias( RTE_STR(p)))) > > > > > > Is it working with clang and icc? > > No idea. It should work with clang (though I don't have it installed at the > > moment), as the docs say the .symver directive is supported > > > > as for icc, thats out of my control completely, as I don't have any access to > > it. > > > > > Why not just define foo as foo_v2? > > I'm not sure what you mean here. Are you suggesting that we just change the abi > > so applications have to call foo_v2 rather than foo when we change the > > prototype. I suppose we could do that, but that seems like it would be an awful > > irritant to users. They would rather have a single symbol to call if it does > > the same function. > > > > > As this is the equivalent of BIND_DEFAULT_SYMBOL for the static case, > > > it would be easier to mix them in only one macro. > > > > > Because of where its used. If you use BIND_DEFAULT_SYMBOL to do the work of > > MAP_STATIC_SYMBOL, every compilation unit will define its own alias and you'll > > get symbol conflicts. > > Oh, you mean it shouldn't be used in a .h file? > If so, this limitation should be noted in the description above. > Its already noted in the example, I'd rather not make a unilateral statement about where to use it above because there can be cause to use it internally as well. > OK for that solution, that's the best we have at the moment. >