From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; 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: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvhedgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepffdvuddvhefhteevtdeuffdtleduuefhfeeujeehteegveevieff vddtffetuedvnecuffhomhgrihhnpehsohhurhgtvgifrghrvgdrohhrghenucfkphepje ejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: 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 To: Neil Horman , Harini Ramakrishnan , Fady Bader Cc: dev@dpdk.org, Omar Cardona , Pallavi Kadam , Ranjit Menon , 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: <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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).