From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by dpdk.org (Postfix) with ESMTP id 0E1AFC5C4 for ; Sun, 28 Jun 2015 22:14:42 +0200 (CEST) Received: by wicnd19 with SMTP id nd19so55051880wic.1 for ; Sun, 28 Jun 2015 13:14:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=BsVAmA1s3cYA0aS0dF57aw2EsZlbgpttBUEeHEFtUs8=; b=hV8MWF3WffWafd0A/jNXXzbJ8KJRyX49naW/ShTkIUOm693KOdtAs2VHRbXWl8ABCX BCif6Ayewew8Cnno0AlLkst8jRttzgJDZCz6S3jTwfRgIVWFxEQMi8JIAICQngQ0vgzO RuWS5ZEr2UJj2DhP32+qzEPxj39nEHyo78r2ck5Jp5IbQKtcJG9QcTD4jfP8zzfNjQmM eCez7goBQ8o1NmJir+9fEGhgtj2HOlWAgnO3P+Rjs73l+JrmV1QAF6tMv8ZlqpRMn4dz eEJW8bGDKqNBmStDcbke2wlkdKP1Vp0D6sA/5POfUnyGi/wDDJtrh9nqvGx+qbSNxdsS IwcQ== X-Gm-Message-State: ALoCoQnY8vnNqhRnmQXcsx98tIiYVljyzEZ057MZq6VbPt3ai+nRL32FHNtVVniGNZi/gG82i5sI X-Received: by 10.194.81.67 with SMTP id y3mr22013531wjx.7.1435522480829; Sun, 28 Jun 2015 13:14:40 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id fm8sm8784691wib.9.2015.06.28.13.14.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Jun 2015 13:14:39 -0700 (PDT) From: Thomas Monjalon To: Neil Horman Date: Sun, 28 Jun 2015 22:13:31 +0200 Message-ID: <2152455.CiuiDMrZSi@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: <20150626143005.GA27458@hmsreliant.think-freely.org> References: <1435088014-18973-1-git-send-email-nhorman@tuxdriver.com> <3172025.YLFsvjgh6J@xps13> <20150626143005.GA27458@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Sun, 28 Jun 2015 20:14:42 -0000 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. OK for that solution, that's the best we have at the moment.