DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Harini Ramakrishnan <harini.ramakrishnan@microsoft.com>,
	Omar Cardona <ocardona@microsoft.com>,
	Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>,
	navasile@linux.microsoft.com,
	Dmitry Malloy <dmitrym@microsoft.com>
Cc: dev@dpdk.org, Pallavi Kadam <pallavi.kadam@intel.com>,
	Ranjit Menon <ranjit.menon@intel.com>,
	Tal Shnaiderman <talshn@mellanox.com>,
	Tasnim Bashar <tbashar@mellanox.com>,
	fady@mellanox.com
Subject: Re: [dpdk-dev] [PATCH 6/6] doc: guide for Windows build using MinGW-w64
Date: Wed, 29 Apr 2020 15:57:48 +0200	[thread overview]
Message-ID: <7353744.c9vzh5UkMf@thomas> (raw)
In-Reply-To: <20200217092718.3c4def72@Sovereign>

Hi,

We didn't get a confirmation from Microsoft about the TLS problem.
Please could we have a status?

Should we mark shared library linkage as not supported in Windows DPDK?
Is there a difference between clang and MinGW?


17/02/2020 07:27, Dmitry Kozlyuk:
> > Remembered another issue: thread-local storage (TLS) with shared libraries.
> > Windows PE doesn't support TLS via special sections, so compilers use TLS
> > emulation layer. With static libraries, there are no issues described below.
> > 
> > The first aspect is a build-time issue of MinGW. When linking to DPDK shared
> > libraries, errors occur:
> > 
> > 	undefined reference to `__emutls_v.per_lcore__rte_errno'
> > 	undefined reference to `__emutls_v.per_lcore__rte_lcore_id'
> > 
> > DPDK declares per_lcore__XXX in a map file, but GCC places __thread symbols
> > in __emutls_v section, so the proper name to export becomes __emutls_v.XXX.
> > This can be worked around by using an additional version script with MinGW,
> > as I do in my port [0], however, the proper solution would be fixing the bug
> > on MinGW side [1]. MinGW already converts TLS variable names when generating
> > DEF files with `-Wl,--output-def` option (not used by DPDK, just a hint).
> 
> Did some research and AFAICT, there is not effortless solution for
> efficient per-lcore variables on Windows. While MinGW-w64 has aforementioned
> issues (actually, GCC on Windows does), Clang with default TLS options just
> generates wrong results when exporting variables from dynamic libraries.
> Demo: https://github.com/PlushBeaver/tlstest
> 
> Thread [0] claims this is a fundamental problem with PE-COFF executable
> format, but I honestly lack expertise to tell if this is valid. Microsoft
> docs [1] suggests that exporting __thread variables won't just work. Can
> someone from Microsoft or from UNH Lab comment further?
> 
> [0]: https://sourceforge.net/p/mingw-w64/mailman/message/31777672/
> [1]:
> https://docs.microsoft.com/en-us/windows/win32/dlls/using-thread-local-storage-in-a-dynamic-link-library




  reply	other threads:[~2020-04-29 13:57 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31  3:07 [dpdk-dev] [PATCH 0/6] MinGW-w64 support Dmitry Kozlyuk
2020-01-31  3:07 ` [dpdk-dev] [PATCH 1/6] eal: introduce portable format attribute Dmitry Kozlyuk
2020-01-31  3:07 ` [dpdk-dev] [PATCH 2/6] eal: use " Dmitry Kozlyuk
2020-01-31  3:07 ` [dpdk-dev] [PATCH 3/6] cmdline: " Dmitry Kozlyuk
2020-01-31  3:07 ` [dpdk-dev] [PATCH 4/6] build: MinGW-w64 support for Meson Dmitry Kozlyuk
2020-02-04 22:08   ` Thomas Monjalon
2020-02-04 23:21     ` Dmitry Kozlyuk
2020-02-05  0:41       ` Thomas Monjalon
2020-02-05 14:30         ` Bruce Richardson
2020-02-05 20:41           ` Dmitry Kozlyuk
2020-02-06 10:59             ` Bruce Richardson
2020-02-07 19:27               ` Dmitry Kozlyuk
2020-01-31  3:07 ` [dpdk-dev] [PATCH 5/6] build: add cross-file for MinGW-w64 Dmitry Kozlyuk
2020-02-04 22:14   ` Thomas Monjalon
2020-02-04 23:23     ` Dmitry Kozlyuk
2020-01-31  3:07 ` [dpdk-dev] [PATCH 6/6] doc: guide for Windows build using MinGW-w64 Dmitry Kozlyuk
2020-02-04 22:34   ` Thomas Monjalon
2020-02-04 23:57     ` Dmitry Kozlyuk
2020-02-05  2:20       ` Thomas Monjalon
2020-02-09 21:39         ` Dmitry Kozlyuk
2020-02-17  6:27           ` Dmitry Kozlyuk
2020-04-29 13:57             ` Thomas Monjalon [this message]
2020-02-05  1:49 ` [dpdk-dev] [EXTERNAL] [PATCH 0/6] MinGW-w64 support Narcisa Ana Maria Vasile
2020-02-05  5:43   ` Dmitry Kozlyuk
2020-02-05  9:26     ` David Marchand
2020-02-05 20:59       ` Dmitry Kozlyuk
2020-02-05 21:02         ` Narcisa Ana Maria Vasile
2020-02-05 21:21           ` Dmitry Kozlyuk

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=7353744.c9vzh5UkMf@thomas \
    --to=thomas@monjalon.net \
    --cc=dev@dpdk.org \
    --cc=dmitry.kozliuk@gmail.com \
    --cc=dmitrym@microsoft.com \
    --cc=fady@mellanox.com \
    --cc=harini.ramakrishnan@microsoft.com \
    --cc=navasile@linux.microsoft.com \
    --cc=ocardona@microsoft.com \
    --cc=pallavi.kadam@intel.com \
    --cc=ranjit.menon@intel.com \
    --cc=talshn@mellanox.com \
    --cc=tbashar@mellanox.com \
    /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).