From: Andre Muezerie <andremue@linux.microsoft.com>
To: David Marchand <david.marchand@redhat.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH v2 3/5] eal: update versioning macros
Date: Thu, 6 Mar 2025 07:53:02 -0800 [thread overview]
Message-ID: <20250306155302.GC28298@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> (raw)
In-Reply-To: <CAJFAV8xtTE9nfCXLNm_4htFDSohs3=feCsNotDRxQU589rfxEA@mail.gmail.com>
On Thu, Mar 06, 2025 at 01:59:34PM +0100, David Marchand wrote:
> On Wed, Feb 19, 2025 at 2:40 AM Andre Muezerie
> <andremue@linux.microsoft.com> wrote:
> >
> > When compiling with MSVC the error below shows up due to function
> > versioning:
> >
> > ../lib/net/rte_net_crc.c(418): error C2061: syntax error:
> > identifier '__attribute__'
> >
> > MSVC allows alias function names to be exported, but the mechanism is
> > different than the one used by gcc. It was considered to enhance the logic
> > in the existing version.map files but that file is also passed to other
> > tools on Linux, making this challenging. A simpler approach is to have an
> > optional version.map file to be used only when Microsoft's linker is to be
> > used. This optional map file is only necessary for libraries that have
> > versioned code.
> >
> > Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>
> > ---
> > lib/eal/include/rte_function_versioning.h | 19 +++++++++++++++++++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/lib/eal/include/rte_function_versioning.h b/lib/eal/include/rte_function_versioning.h
> > index eb6dd2bc17..aa3165a659 100644
> > --- a/lib/eal/include/rte_function_versioning.h
> > +++ b/lib/eal/include/rte_function_versioning.h
> > @@ -82,6 +82,13 @@
> > */
> > #define MAP_STATIC_SYMBOL(f, p)
> >
> > +/*
> > + * MAP_STATIC_BASE_SYMBOL
> > + * Has the same purpose as MAP_STATIC_SYMBOL, but takes a base function name
> > + * instead of the whole function prototype. It is used to support MSVC.
> > + */
> > +#define MAP_STATIC_BASE_SYMBOL(b, p)
> > +
> > #else
> > /*
> > * No symbol versioning in use
> > @@ -90,7 +97,19 @@
> > #define VERSION_SYMBOL_EXPERIMENTAL(b, e)
> > #define __vsym
> > #define BIND_DEFAULT_SYMBOL(b, e, n)
> > +
> > +#ifdef RTE_TOOLCHAIN_MSVC
> > +#define MAP_STATIC_SYMBOL(f, p)
>
> I would prefer we trigger an explicit error when some code calling
> MAP_STATIC_SYMBOL() is built with MSVC.
>
>
> > +#define MAP_STATIC_BASE_SYMBOL(b, p) __pragma(comment(linker, "/alternatename:" #b "=" #p))
> > +/*
> > + * version.map file should also be updated with "b=p;", like
> > + * rte_net_crc_set_alg=rte_net_crc_set_alg_v26;
> > + */
> > +#else
> > #define MAP_STATIC_SYMBOL(f, p) f __attribute__((alias(RTE_STR(p))))
> > +#define MAP_STATIC_BASE_SYMBOL(b, p)
> > +#endif
> > +
>
> But in any case, I don't like as we end up with one macro for each linker.
>
> I have been thinking about this topic, and I sent a RFC series, please
> have a look.
> https://patchwork.dpdk.org/project/dpdk/list/?series=34798
>
> I hope this type of approach will also make it possible to stop
> converting from GNU linker type version.map commited in DPDK to
> Windows linker format.
>
I like what you're proposing. This makes DPDK less coupled with the GNU linker and
therefore easier to be supported by other toolsets.
>
> --
> David Marchand
next prev parent reply other threads:[~2025-03-06 15:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-10 21:51 [PATCH] mbuf: enable to be compiled with MSVC Andre Muezerie
2025-02-10 22:34 ` Stephen Hemminger
2025-02-11 2:19 ` Andre Muezerie
2025-02-12 14:23 ` Thomas Monjalon
2025-02-12 16:24 ` Thomas Monjalon
2025-02-19 1:39 ` [PATCH v2 0/5] " Andre Muezerie
2025-02-19 1:39 ` [PATCH v2 1/5] doc: update guide on versioning macros Andre Muezerie
2025-02-19 1:39 ` [PATCH v2 2/5] buildtools: update map_to_win.py to use optional map file Andre Muezerie
2025-02-19 1:39 ` [PATCH v2 3/5] eal: update versioning macros Andre Muezerie
2025-03-06 12:59 ` David Marchand
2025-03-06 15:53 ` Andre Muezerie [this message]
2025-02-19 1:39 ` [PATCH v2 4/5] net: update use of " Andre Muezerie
2025-02-19 1:39 ` [PATCH v2 5/5] mbuf: enable to be compiled with MSVC Andre Muezerie
2025-02-20 20:31 ` [PATCH v3 0/6] " Andre Muezerie
2025-02-20 20:31 ` [PATCH v3 1/6] doc: update guide on versioning macros Andre Muezerie
2025-02-20 20:31 ` [PATCH v3 2/6] buildtools: update map_to_win.py to use optional map file Andre Muezerie
2025-02-20 20:31 ` [PATCH v3 3/6] eal: update versioning macros Andre Muezerie
2025-02-20 20:31 ` [PATCH v3 4/6] devtools: check ms linker map files Andre Muezerie
2025-02-20 20:31 ` [PATCH v3 5/6] net: update use of versioning macros Andre Muezerie
2025-02-20 20:31 ` [PATCH v3 6/6] mbuf: enable to be compiled with MSVC Andre Muezerie
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=20250306155302.GC28298@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net \
--to=andremue@linux.microsoft.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).