Re: [Mingw-w64-public] [PATCH 07/18] winpthreads: Fix TLS thread callback initializers on MSVC x64
On Thu, 30 Nov 2023, Antonin Décimo wrote:
The literature online uses `data_seg` on x86 and `const_seg` on x64.
In my tests, using `const_seg` worked on all arches (x86, x64, arm,
arm64).
Hmm, that does indeed seem to be the case - I can confirm this.
We can use `#pragma section` and `__declspec(allocate("xxx"))`
instead.
Umm, this doesn't seem to work for me. With your example code below, with
foo_init renamed into main(), I don't get any working TLS callbacks, on
neither x86 nor x64, and linking produces the following warning:
LIBCMT.lib(tlssup.obj) : warning LNK4078: multiple '.CRT' sections found
with different attributes (40400040)
LIBCMT.lib(initializers.obj) : warning LNK4254: section '.CRT' (5040)
merged into '.rdata' (4040) with different attributes
This is tested and observed with MSVC 2022 17.8.0 and 17.9.1 preview 1.
If I replace your #pragma section with #pragma const_seg, it does work
though.
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] cannot execute ./configure
The MinGW-w64 project only provides the software needed to make a GCC toolchain on Windows. Since you are trying to execute "configure", which is a shell script, you need to get a shell like Bash running on your computer, and that is outside of the scope of the MinGW project. I recommend ignoring whatever you downloaded earlier and installing MSYS2, which comes with Bash and a package manager you can use to install MinGW toolchains: https://www.msys2.org/ If you ask a question on StackOverflow.com and tag it with "msys2", I will see it. Be sure to provide all the specific details about what you are trying to compile, what MSYS2 environment you are using, what MSYS2 packages you installed, what you tried, and the full error messages you got. --David Grayson On Thu, Nov 30, 2023 at 9:09 AM Frère Justin - Jérusalem < frere.jus...@fraternites-jerusalem.org> wrote: > Hi there... I installed mingw64 for windows a year ago or so. I'm trying to > install a library for unix. I have downloaded the source file and > uncompressed it; in order to finalize the installation, I mut run > ./configure (I guess from the mingw64 directory) but then I get the > following error message (I translate from italian): "." is not recognized > as an internal or external command, an executable file or a batch file > Do you figure out what I'm missing ? Thx ! > > Justin > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] cannot execute ./configure
Hi there... I installed mingw64 for windows a year ago or so. I'm trying to install a library for unix. I have downloaded the source file and uncompressed it; in order to finalize the installation, I mut run ./configure (I guess from the mingw64 directory) but then I get the following error message (I translate from italian): "." is not recognized as an internal or external command, an executable file or a batch file Do you figure out what I'm missing ? Thx ! Justin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 14/18] winpthreads: AC_PROG_RANLIB is obsoleted by LT_INIT
在 2023/11/30 18:54, Antonin Décimo 写道: Are you sure it's a good idea? Isn't it better if the two files are kept in sync? It's less confusing during the occasional bisect. In OCaml, we even have continuous integration testing that configure is regenerated on configure.ac changes. Changes to generated files can't be reviewed or cherry-picked; and they may be overwritten anyway. So there is no necessity to include them. They will be committed separately. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 07/18] winpthreads: Fix TLS thread callback initializers on MSVC x64
Le jeu. 30 nov. 2023 à 14:20, Martin Storsjö a écrit :
>
> On Wed, 29 Nov 2023, Martin Storsjö wrote:
>
> >> and related code in Chromium [2].
> >> The first doesn't mention ARM, but both use const_seg on 64-bits
> >> arches and data_seg on 32 bits.
> >
> > I wouldn't really take that as an authority for this matter here - I would
> > expect this to be a similar historical mistake; someone has used _WIN64 to
> > distinguish x86 and x64 at a time when no other architectures were relevant
> > in Windows code.
> >
> >>
> >> [1]:
> >> https://lallouslab.net/2017/05/30/using-cc-tls-callbacks-in-visual-studio-with-your-32-or-64bits-programs/
> >> [2]:
> >> https://chromium.googlesource.com/chromium/src/+/lkgr/base/win/dllmain.cc#64
> >>
> >> I'll try to write a sensible repro case and build it on all arches. I
> >> don't have ARM Windows machines, I hope that looking at the
> >> cross-compiled executable sections will be enough.
> >
> > Sure, hopefully inspecting that is enough. Otherwise I can help out running
> > any test binaries you want to inspect (you can probably mail me off-list for
> > that).
>
> I went ahead and tested this myself - and as expected, _WIN64 is indeed
> the wrong condition.
>
> ARM and ARM64 all use the same section type as x64, it's only x86 which is
> the odd one out. So like most other similar cases, you'll need to ifdef
> for e.g. _M_IX86 and use the other common codepath for the rest. It might
> be good to add a comment that explicitly clarifies which one each of the 4
> architectures needs (to indicate that the ifdef isn't a mistake but an
> intentional choice).
Thanks for noticing this and prompting me to triple-check the code.
Turns out we do have an ARM Windows laptop in my company :-)
The literature online uses `data_seg` on x86 and `const_seg` on x64.
In my tests, using `const_seg` worked on all arches (x86, x64, arm,
arm64). We can use `#pragma section` and `__declspec(allocate("xxx"))`
instead. Testing code now looks like this (without comments).
Note that `#pragma comment (linker, "/INCLUDE:_foo_tls_callback")` is
necessary otherwise the callback symbol is removed with Link-Time
Optimization (LTO).
I think I may have found a bug with MSVC: if you use LTO and
optimization (-O1 or -O2), then the symbol is always discarded. I'll
open a bug report and see what happens.
Does the example below look reasonable?
Many thanks,
-- Antonin
#include
#include
#define STR(x) #x
static DWORD callback_reason = MAXDWORD;
#if defined (_M_IX86)
#pragma comment (linker, "/INCLUDE:__tls_used")
#pragma comment (linker, "/INCLUDE:__foo_tls_callback")
#elif defined (_WIN64) || defined (_M_ARM)
#pragma comment (linker, "/INCLUDE:_tls_used")
#pragma comment (linker, "/INCLUDE:_foo_tls_callback")
#endif
static void NTAPI __stdcall
foo_tls_callback(PVOID DllHandle, DWORD dwReason, PVOID Reserved)
{
UNREFERENCED_PARAMETER(DllHand
le);
UNREFERENCED_PARAMETER(dwReason);
UNREFERENCED_PARAMETER(Reserved);
callback_reason = dwReason;
}
#ifdef _MSC_VER
#pragma section(".CRT$XLF", long, read, shared)
#endif
const PIMAGE_TLS_CALLBACK
#if defined __GNUC__
__attribute__((__section__(".CRT$XLF")))
#elif defined _MSC_VER
__declspec(allocate(".CRT$XLF"))
#endif
_foo_tls_callback = foo_tls_callback;
void foo_init(void) {
switch(callback_reason) {
case MAXDWORD: printf("foo_tls_callback didn't fire.\n");
ExitProcess(1); break;
case DLL_PROCESS_ATTACH: printf(STR(DLL_PROCESS_ATTACH) "\n"); break;
case DLL_PROCESS_DETACH: printf(STR(DLL_PROCESS_DETACH) "\n"); break;
case DLL_THREAD_ATTACH: printf(STR(DLL_THREAD_ATTACH) "\n"); break;
case DLL_THREAD_DETACH: printf(STR(DLL_THREAD_DETACH) "\n"); break;
}
}
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 07/18] winpthreads: Fix TLS thread callback initializers on MSVC x64
On Wed, 29 Nov 2023, Martin Storsjö wrote: and related code in Chromium [2]. The first doesn't mention ARM, but both use const_seg on 64-bits arches and data_seg on 32 bits. I wouldn't really take that as an authority for this matter here - I would expect this to be a similar historical mistake; someone has used _WIN64 to distinguish x86 and x64 at a time when no other architectures were relevant in Windows code. [1]: https://lallouslab.net/2017/05/30/using-cc-tls-callbacks-in-visual-studio-with-your-32-or-64bits-programs/ [2]: https://chromium.googlesource.com/chromium/src/+/lkgr/base/win/dllmain.cc#64 I'll try to write a sensible repro case and build it on all arches. I don't have ARM Windows machines, I hope that looking at the cross-compiled executable sections will be enough. Sure, hopefully inspecting that is enough. Otherwise I can help out running any test binaries you want to inspect (you can probably mail me off-list for that). I went ahead and tested this myself - and as expected, _WIN64 is indeed the wrong condition. ARM and ARM64 all use the same section type as x64, it's only x86 which is the odd one out. So like most other similar cases, you'll need to ifdef for e.g. _M_IX86 and use the other common codepath for the rest. It might be good to add a comment that explicitly clarifies which one each of the 4 architectures needs (to indicate that the ifdef isn't a mistake but an intentional choice). // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 14/18] winpthreads: AC_PROG_RANLIB is obsoleted by LT_INIT
Le jeu. 30 nov. 2023 à 08:11, JonY via Mingw-w64-public a écrit : > > On 11/29/23 10:39, Antonin Décimo wrote: > > Fixes a warning from libtoolize: 'AC_PROG_RANLIB' is rendered obsolete > > by 'LT_INIT'. > > > > Signed-off-by: Antonin Décimo > > --- > > mingw-w64-libraries/winpthreads/configure| 104 +-- > > mingw-w64-libraries/winpthreads/configure.ac | 1 - > > 2 files changed, 1 insertion(+), 104 deletions(-) > > > > Please exclude the configure file itself from the commit, regenerate it > as a separate commit. Are you sure it's a good idea? Isn't it better if the two files are kept in sync? It's less confusing during the occasional bisect. In OCaml, we even have continuous integration testing that configure is regenerated on configure.ac changes. The configure file was regenerated on MSYS2 with WANT_AUTOMAKE=1.16 autoreconf -fiv Best regards, -- Antonin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
