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 at DPDK_1 and the latter is mapped to foo at > > > 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. OK for that solution, that's the best we have at the moment.