Re: [dpdk-dev] [PATCHv3 2/3] rte_compat: Add MAP_STATIC_SYMBOL macro

[Neil Horman <nhorman@tuxdriver.com>]

On Sun, Jun 28, 2015 at 10:13:31PM +0200, Thomas Monjalon wrote:
> 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.
> 
Its already noted in the example, I'd rather not make a unilateral statement
about where to use it above because there can be cause to use it internally as
well.

> OK for that solution, that's the best we have at the moment.
>