We don't strictly need it, we can redirect to the right function
using __MINGW_ASM_CALL() in the headers - this function was only
added in c9eca28decb3aa5213fe22ab1f9883df91d79806 to fix the most
immediate breakage after 581532b8e49a0e10cbdfe2332a8c1d61ff3d6820.
Note that we do need to keep ucrt_ms_fwprintf.c; CRT independent
files in libmingwex.a do reference __ms_fwprintf, so we need to
provide it as an actual symbol.
Signed-off-by: Martin Storsjö <martin@martin.st>
In principle, we could maybe also do this for CRTs other than
UCRT; there we currently define these aliases in def files.
This fixes breakage after 581532b8e49a0e10cbdfe2332a8c1d61ff3d6820,
noted and discussed at
b1b6eb5c5d.
Previously, c9eca28decb3aa5213fe22ab1f9883df91d79806 fixed the
initial issues by providing one function as a separate standalone
function, however that approach seems unsustainable to do for all
functions.
Signed-off-by: Martin Storsjö <martin@martin.st>
Declaration of all these functions is currently hidden inside !_UCRT
block. Move them outside of the block, so they are always visible.
Signed-off-by: Martin Storsjö <martin@martin.st>
Now these functions should respect UCRT stdio flags set by
assigning to _CRT_INTERNAL_LOCAL_PRINTF_OPTIONS, so there's no need
to keep them inline. Making them non-inline helps referring to
them via a plain symbol, using __MINGW_ASM_CALL().
fwprintf was already non-inline (since the start), and since
30c0b623dbaf9dcc218c9068625f5e8dddd57aab we no longer provided
an inline version of it.
Signed-off-by: Martin Storsjö <martin@martin.st>
The existing form stems from the very early stages of the UCRT
implementation in mingw-w64; there is no reason why we shouldn't
honor the default settings of the executable here.
Signed-off-by: Martin Storsjö <martin@martin.st>
Now that these options can be set globally (within an executable),
we should honor it within the non-inline functions as well.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes things closer match how this works in MSVC.
A few minor details still differ though: In MS UCRT headers,
the __local_stdio_{printf,scanf}_options functions are inline
in the public headers. I don't see any technical advantage in
doing that (and getting that kind of inline correct in C is tricky).
This makes it possible to set the flags at runtime, by assigning
to _CRT_INTERNAL_LOCAL_PRINTF_OPTIONS. This also makes it
possible to affect the flags of our non-inline UCRT stdio
functions, like stdio/ucrt_printf.c and similar ones.
In MSVC, these flags are adjustable in many different ways. I
haven't found any docs that explicitly describe which mechanisms
are intended to be used, and which ones should be avoided:
1. One can define e.g. _CRT_INTERNAL_LOCAL_PRINTF_OPTIONS to a
different constant value while compiling. In MSVC, this does
affect all functions (as all are defined inline in headers).
In the mingw-w64 headers, this only affects the functions that
are defined inline (currently mostly the wide char functions).
2. One can assign to e.g. _CRT_INTERNAL_LOCAL_PRINTF_OPTIONS at
runtime. Previously this wasn't supported in mingw-w64, now it
becomes supported. Doing this now affects the non-inline functions
too.
3. In MSVC, one can define _CRT_STDIO_ISO_WIDE_SPECIFIERS or
_CRT_STDIO_LEGACY_WIDE_SPECIFIERS while compiling. This adds
directives, pulling in an extra library, which adds a constructor
function, which on startup sets or clears bits in
_CRT_INTERNAL_LOCAL_PRINTF_OPTIONS, depending on the choice.
This is the mechanism that is closest to being documented (it
was mentioned in a blog post [1], although the behaviour change
advertised in that blog post was later reverted before release).
We currently don't have anything corresponding to this.
4. One can also call e.g. __local_stdio_printf_options directly
and assign to it. We should now be fully compatible with this.
It's unclear how many projects attempt to do any of this at all;
if they do, it's probably most plausible that they do 3 or 2.
In MSVC, the options flags are statically initialized to zero,
while another startup routine
(__scrt_initialize_default_local_stdio_options) sets their initial
values. Here we just statically initialize them to their default
values.
[1] https://devblogs.microsoft.com/cppblog/c-runtime-crt-features-fixes-and-breaking-changes-in-visual-studio-14-ctp1/
Signed-off-by: Martin Storsjö <martin@martin.st>
All the other files directly call the right __stdio_common
function rather than calling the next level layered function
(e.g. printf->vprintf->vfprintf).
Signed-off-by: Martin Storsjö <martin@martin.st>
This reverts commit 91459ac35276522b0e4405c76795d91822bb395a.
That commit was a workaround for older binutils or LLD versions,
that would otherwise autoexport symbols from the CRT libraries.
Since 9d9c67b06c1bf4c4550e3de0eb575c2bfbe96df9 in binutils (in 2017),
binutils does exclude "libmsvcrt", "libmsvcrt-os" and "libucrtbase"
from autoexport; likewise, LLD also learnt to exclude "libmsvcrt"
and "libucrtbase" in 6bde1667bac6d474c70cdcf3f2388d32726f76b7
in 2017. So by now, it should be more than safe to remove the
workaround. (And even with older linkers, the only issue is that
more symbols than wanted are autoexported.)
Therefore, revert this workaround, to stop providing __imp_ prefixed
symbols for symbols that aren't accessed with dllimport anywhere.
Not all symbols that were added in that commit are removed; ones
declared in public or internal headers as _CRTIMP are kept.
Also remove similar cases in new ucrt_*.c files that have been
added since. All such cases are removed except for _vscprintf,
as that function uses a declaration with _CRTIMP even for UCRT.
Signed-off-by: Martin Storsjö <martin@martin.st>
Enable underscored fpreset alias for ARM targets in crt-aliases.def.in
include file, which is automatically included into all msvcr*.def.in and
ucrt*.def.in files.
Underscored alias is still present in api-ms-win-crt-runtime-l1-1-0.def.in
file as api-ms-win-crt*.def.in files do not use crt-aliases.def.in yet.
This change fixes more issues with commit 87ec8e6c5a62 ("crt: Use .def
files for fpreset and _fpreset on ARM targets.") which:
- enabled underscored alias also for i386 and x64 msvcr120_app.dll builds
- forgot to add underscored alias for arm32 msvcr110.dll builds
- added duplicated code into individual msvcr*.def.in files, which was already de-duplicated
- removed comment about DATA keywords (manually added needs to be revisited)
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
This file is intended to override fpreset for extended precision on x86,
where long double is 10 bytes.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Reapply commits d60d431d26d6 ("crt: ucrtbase.def.in: Fix ARM64 symbols")
and 52c98b1273a6 ("crt: ucrtbase.def.in: Fix symbols not available on I386
and X64") for api-ms-win-crt-*.def.in files.
Signed-off-by: Martin Storsjö <martin@martin.st>
These files are already in a target-specific directory, and it's the build
system's job to include them only for applicable targets.
This also allows their use for ARM64EC.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Since the current mingw-w64 uses a different layout for fenv_t and constant
values, this changes the ABI.
Based on Wine code by Piotr Caban, Alexandre Julliard and Martin Storsjö, who
granted permission to use it under the mingw-w64 license.
Unlike earlier versions, msvcr120 and UCRT implement fenv.h, but their
representation differs from what mingw-w64 has used so far. fenv_t has a
target-independent layout and flags, requiring translation to and from
machine-specific flags. Generic helpers handle this conversion.
On Windows x86_64, these functions operate only on SSE registers, ignoring x87.
Since mingw long doubles use x87 and some mingw-w64-crt math functions are
implemented in terms of x87, they would be unaffected by these calls. This
patch does not follow that behavior; instead, it modifies x87 registers as well,
effectively following the 32-bit x86 code path.
Additionally, in 32-bit versions older than msvcr71, functions like _control87,
__control87_2, and _statusfp did not support SSE, even though they would
otherwise be useful as helpers. This patch provides variants that operate on
both SSE and x87 for x86 and x86_64 (though we could still consider a different
approach for ARM targets).
I left FE_*_ENV handling unchanged, but we could consider making them proper
pointers to structs filled with the appropriate values instead.
This patch also adds support for ARM64EC. The ARM64EC version currently ignores
x87, as 80-bit long doubles are not supported anyway.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
When `__MINGW_MSVC_COMPAT_WARNINGS` is defined, the plain (non-template)
functions are always deprecated, and template overloads are not to be marked
with `__MINGW_ATTRIB_DEPRECATED_SEC_WARN` anyway.
Previously these warnings could not be disabled for C.
Reference: https://sourceforge.net/p/mingw-w64/mailman/message/59152860/
Signed-off-by: LIU Hao <lh_mouse@126.com>
Now all I386 symbols in lib-common/ws2_32.def.in file are defined with
stdcall @<num> suffixes. These suffixes are automatically removed for
non-I386 builds by Makefile.am rule during processing of
lib-common/*.def.in files.
During merging of lib32/ws2_32.def and lib-common/ws2_32.def.in files,
all symbols were sorted in the final file.
Signed-off-by: Martin Storsjö <martin@martin.st>
This allows to define in lib-common/*.def.in files symbols with I386
stdcall @<num> suffixes and therefore have one common def file for all
platforms.
Removal of @<num> suffixes is done by following sed regex:
sed -E 's/^([^ ]+)@[0-9]+( |$)/\1\2/'
Note that dollar character in Makefile is duplicated to prevent treating it
as variable in Makefile.
This regex was checked on following test cases:
Test@4
Test1@4 ; comment
Test2@4 == Test22
Test3@4 @8
Test@4@8
Test@5test@8
@Test6@8
The result is:
Test
Test1 ; comment
Test2 == Test22
Test3 @8
Test@4
Test@5test
@Test6
That regex handles comments, ordinal numbers and also leading @ chars which
are part of the symbols.
Signed-off-by: Martin Storsjö <martin@martin.st>
CRT DLL libraries older than msvcrt40 use internally in all time functions
dst bias of one hour. These DLL libraries do not export _dstbias variable
and neither __dstbias() and __p__dstbias() functions.
So for these CRT import libraries define import variable _dstbias with
fixed value -3600 (one hour) and include __dstbias() and __p__dstbias()
compatible functions (which returns pointer to _dstbias import variable).
With these definitions, it is possible to compile and link applications
which uses _dstbias (included from mingw-w64 time.h and defined as call to
__dstbias() function) with crtdll.dll, msvcrt10.dll or msvcrt20.dll. And
application via _dstbias will receive the dst bias which the CRT library is
currently using (like when linked with any other new CRT library).
Signed-off-by: Martin Storsjö <martin@martin.st>
Symbol aliases __p__daylight/__p__dstbias/__p__timezone/__p__tzname are
already present in crt-aliases.def.in for ucrtbase.dll builds since commit
469e8e419bbe ("crt: Provide __daylight(), __dstbias(), __timezone() and
__tzname() functions for pre-msvcr80 builds") but are not present in
api-ms-win-crt-time-l1-1-0.def.in for regular UCRT builds. Fix it.
Signed-off-by: Martin Storsjö <martin@martin.st>
