From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 30FC5A00BE;
Wed, 27 May 2020 23:43:54 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 586921DA5C;
Wed, 27 May 2020 23:43:53 +0200 (CEST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
[66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 3F6D81DA4C
for <dev@dpdk.org>; Wed, 27 May 2020 23:43:52 +0200 (CEST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47])
by mailout.nyi.internal (Postfix) with ESMTP id CC4145C0057;
Wed, 27 May 2020 17:43:51 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
by compute7.internal (MEProxy); Wed, 27 May 2020 17:43:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
from:to:cc:subject:date:message-id:in-reply-to:references
:mime-version:content-transfer-encoding:content-type; s=fm1; bh=
3+okH5xeuK7o98fRNF/NLlOZyzzsKyDoFD4VlHFhE5g=; b=FqsFRQvY/NL2zYM4
7wfysYeUPsA7JEOBby3EOnNp/8kFFnaA5jNdaixdtPctF2W4kbxQdIjd9elyeSMZ
b1GSRNQx9gcZ8C3ScheXFuJdPGR2u6g/MDvo9+U4IPZ8MH7thZxFzQaOFsd2bHmG
KhpobOS/A2LSCi+p+vjlxtj/vJZKgs6OEaZK3d9YIQyaoLQvi4UiPt2ls8KfG0FU
/pBZBMzN2ISkAget4kjjnCDtUel+t42ODkSBH1us4hh78+KPXx7PCdHs6YmLkDhP
RHIeFAUw8SIs3BJSBi1CreFuFFytn+Pi3XRo7yA3j7s64UAWpC1TQHjvDMi4Esx1
mTk++A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-transfer-encoding:content-type
:date:from:in-reply-to:message-id:mime-version:references
:subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
:x-sasl-enc; s=fm2; bh=3+okH5xeuK7o98fRNF/NLlOZyzzsKyDoFD4VlHFhE
5g=; b=rZ933ngAmT5CNigTwcFzBMRn/A7efim9Re7XlPKYAsuBN67Tw6jzZKtMJ
nBwcifcOBez1v9nndUs0HgiD1EYrD2onL//5q67Z8Cfb9xw9s8YcaNVkkNzsQ5n4
A2HOIQoospn8SqIv8cX/UzG+1l5CTTST51UZaKwZj98Xc1c9Z1GG7ntK6gV6fzvm
s1/qmnpHi09uN5Vc8tGtxPJZO8QEErDYQzXNbTyrs8KSQagrbg+U43U2chQCQkCE
RdMK5lhrWJqDVCdJqpUvHlDiPN7HcwANEckIkc9/ao0OaR5YCERw3056P37oi9n6
5DJTRvTrnt8AH1kV2qRKJaAOE8NjQ==
X-ME-Sender: <xms:F9_OXrM-bk6j53XJn7hj7Q8M2DPUAuiHjauI1MqvIaT4RkYUGHwvBg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvhedgtdduucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr
shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg
ftrfgrthhtvghrnhepffdvuddvhefhteevtdeuffdtleduuefhfeeujeehteegveevieff
vddtffetuedvnecuffhomhgrihhnpehsohhurhgtvgifrghrvgdrohhrghenucfkphepje
ejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm
pehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth
X-ME-Proxy: <xmx:F9_OXl-gP8AH-7Kg798XNey81WnaMgnL5YC_WlxxhpFOEDrJqUgceQ>
<xmx:F9_OXqT6IDZ1zHgEgQtPpmCTaOxOALsI46zy5aLo2MokUrlQLWrzBA>
<xmx:F9_OXvt7TTn6ZD_Qem_uZagymZnyjULg1ggRG_p8HVL2sOL7bP1M5w>
<xmx:F9_OXkEcEO3lkbo4AqeavfkqWoBc6lWKDX8tq2wxlfPMqFd3pZ3KtQ>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
by mail.messagingengine.com (Postfix) with ESMTPA id 915713280059;
Wed, 27 May 2020 17:43:50 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Neil Horman <nhorman@tuxdriver.com>,
Harini Ramakrishnan <harini.ramakrishnan@microsoft.com>,
Fady Bader <fady@mellanox.com>
Cc: dev@dpdk.org, Omar Cardona <ocardona@microsoft.com>,
Pallavi Kadam <pallavi.kadam@intel.com>, Ranjit Menon <ranjit.menon@intel.com>,
dmitry.kozliuk@gmail.com, mdr@ashroe.eu
Date: Wed, 27 May 2020 23:43:49 +0200
Message-ID: <6684460.qzksc9xQiS@thomas>
In-Reply-To: <3834007.4YYSKOMRdh@thomas>
References: <AM0PR0502MB4034BCC8160D99C07AA0870EBFB10@AM0PR0502MB4034.eurprd05.prod.outlook.com>
<20200527203503.GA1603965@hmswarspite.think-freely.org>
<3834007.4YYSKOMRdh@thomas>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] ABI versioning in Windows
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
27/05/2020 23:27, Thomas Monjalon:
> 27/05/2020 22:35, Neil Horman:
> > On Wed, May 27, 2020 at 02:50:07PM +0200, Thomas Monjalon wrote:
> > > +Cc more people
> > >
> > > 27/05/2020 12:41, Fady Bader:
> > > > What should we do with the ABI versioning in Windows ?
> > >
> > > I think there are 2 questions here:
> > >
> > > 1/ Do we want to maintain ABI compatibility on Windows like we do for Linux and FreeBSD?
> > > The decision must be clearly documented.
> > >
> > My first notion, without any greater thought is "why wouldn't we". ABI
> > stability is OS agnostic. If a symbol is considered stable, theres no reason
> > that I can think of that it wouldn't be stable for each OS.
>
> Technical reason + no need so far.
>
>
> > > 2/ How do we implement the macros in rte_function_versioning.h for Windows?
> > > Something needs to be done, otherwise we cannot compile libraries having some function versioning.
> > >
> > Can you elaborate on what exactly the issue is here? I presume by your comment
> > above that visual studio either doesn't support symbol level versioning or
> > doesn't support versioning at all?
>
> I don't know how to implement the macros in rte_function_versioning.h for Windows.
>
>
> > If thats the case, and there is a commitment to make dpdk buildable on windows,
> > I suppose the only choice is to make a ifdef WINDOWS section of the
> > rte_function_versioning.h file, and effectively turn all the macros into no-ops.
>
> Yes that's the idea.
> But we still need to implement either BIND_DEFAULT_SYMBOL or MAP_STATIC_SYMBOL
> to alias the latest function version to the actual function symbol.
I've just found a tip in https://sourceware.org/binutils/docs/ld/WIN32.html
It suggests to create a weak symbol:
void foo() __attribute__((weak, alias ("foo_latestversion")));
> > The BIND_DEFAULT_SYMBOL macro looks like it could still work, as MSVC has an
> > alias linker command thats implementable via __pragma, but thats probably all we
> > can do, unless there is some more robust versioning support that I can't find.
>
> What is this pragma?
>
>
> > Note we will also likely need to agument the makefiles/meson files so that the
> > link stage doesn't pass the version script to the linker
>
> Why not using the version script for exported symbols?
> We are already doing it (.def file generated from .map).