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 C340BA00BE; Thu, 28 May 2020 02:28:18 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6A30D1DA97; Thu, 28 May 2020 02:28:17 +0200 (CEST) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 423D91DA91 for ; Thu, 28 May 2020 02:28:16 +0200 (CEST) Received: from 2606-a000-111b-4634-0000-0000-0000-1bf2.inf6.spectrum.com ([2606:a000:111b:4634::1bf2] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1je6Ov-0008Av-OR; Wed, 27 May 2020 20:28:08 -0400 Date: Wed, 27 May 2020 20:28:00 -0400 From: Neil Horman To: Thomas Monjalon Cc: Harini Ramakrishnan , Fady Bader , dev@dpdk.org, Omar Cardona , Pallavi Kadam , Ranjit Menon , dmitry.kozliuk@gmail.com, mdr@ashroe.eu Message-ID: <20200528002800.GB1666585@hmswarspite.think-freely.org> References: <20200527203503.GA1603965@hmswarspite.think-freely.org> <3834007.4YYSKOMRdh@thomas> <6684460.qzksc9xQiS@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6684460.qzksc9xQiS@thomas> X-Spam-Score: -2.9 (--) X-Spam-Status: No 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" On Wed, May 27, 2020 at 11:43:49PM +0200, Thomas Monjalon wrote: > 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"))); > Ahh, you're using mingw, which appears to support versioning. If the windows equivalent of ld.so honors those versions, I would think the versioning bits should almost just work (assuming that mingw supports all the used __attirbutes__) Neil > > > > 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). > > > >