DPDK patches and discussions
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: Harini Ramakrishnan <harini.ramakrishnan@microsoft.com>,
	Fady Bader <fady@mellanox.com>,
	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
Subject: Re: [dpdk-dev] ABI versioning in Windows
Date: Wed, 27 May 2020 20:28:00 -0400
Message-ID: <20200528002800.GB1666585@hmswarspite.think-freely.org> (raw)
In-Reply-To: <6684460.qzksc9xQiS@thomas>

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).
> 
> 
> 
> 

  reply	other threads:[~2020-05-28  0:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27 10:41 Fady Bader
2020-05-27 12:50 ` Thomas Monjalon
2020-05-27 14:32   ` Ray Kinsella
2020-05-27 20:35   ` Neil Horman
2020-05-27 21:27     ` Thomas Monjalon
2020-05-27 21:43       ` Thomas Monjalon
2020-05-28  0:28         ` Neil Horman [this message]
2020-05-28  0:21       ` Neil Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200528002800.GB1666585@hmswarspite.think-freely.org \
    --to=nhorman@tuxdriver.com \
    --cc=dev@dpdk.org \
    --cc=dmitry.kozliuk@gmail.com \
    --cc=fady@mellanox.com \
    --cc=harini.ramakrishnan@microsoft.com \
    --cc=mdr@ashroe.eu \
    --cc=ocardona@microsoft.com \
    --cc=pallavi.kadam@intel.com \
    --cc=ranjit.menon@intel.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git