Some cdecl functions have incorrect stdcall suffix @0 probably due to
false-positive detection by gendef. Remove incorrect suffix.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some cdecl functions have incorrect stdcall suffix @0 probably due to
false-positive detection by gendef. Remove incorrect suffix.
Signed-off-by: Martin Storsjö <martin@martin.st>
Function _adj_fdiv_r in msvcr90d.dll returns like in other msvcrt
libraries. Just gendef is not able to recognize it.
Signed-off-by: Martin Storsjö <martin@martin.st>
These seem to have been missed in
38fa547c16.
This allows using the UCRT functions nexttoward, nexttowardl and
nextafterl on ARM/AArch64. (math/nextafterl.c provides both
the function nextafterl, and nexttowardl.)
On x86, all these functions take one long double parameter, so the
UCRT version can't be used (as the size of long doubles differ
between mingw mode and MSVC mode on x86).
Signed-off-by: Martin Storsjö <martin@martin.st>
Symbols @_calloc_crt@8, @_malloc_crt@4 and @_realloc_crt@8 are exported
from msvcr80 DLL libraries with their @suffix decoration. This is not
usual.
Those decorated symbols refers to fastcall function calling convention.
When generating import library, @suffix must not be trimmed (which is done
by default by mingw-w64 build procedure due to usage of dlltool --kill-at
switch), otherwise linking would fail.
Note that suffix @size for fastcall functions does not refer to size of the
stack used for arguments, but rather to size of all arguments (passed in
registers + stack). All these functions take arguments only in registers.
So fix symbols in import libraries by rename operator '==' like it is
already used for stdcall decorated symbols. dlltool --kill-at switch does
not trim right side of the rename operator '=='.
To make declarations of these functions more readable, introduce a new
FASTCALL_DECORATED_EXPORT() macro for it.
Signed-off-by: LIU Hao <lh_mouse@126.com>
This macro is currently used only for stdcall functions.
Rename it and includes STDCALL into the name to prevent confusion that it
cannot be used for example for fastcall functions (they do not have leading
underscore in name, like stdcall and cdecl).
Signed-off-by: LIU Hao <lh_mouse@126.com>
In followup change will be definition of __argv in stdlib.h changed and
will not use __MINGW_IMP_SYMBOL(__argv) anymore.
So declare __MINGW_IMP_SYMBOL(__argv) in __p___argv.c file manually.
Signed-off-by: Martin Storsjö <martin@martin.st>
Function __p__wpgmptr() returns pointer to global variable _wpgmptr and is
available since VC20, it is available also in UCRT, and also in x86 version
of OS system version msvcrt.dll.
crtdll.dll and msvcrt10.dll do not provide global variable _wpgmptr and
neither __p__wpgmptr() function.
For remaining CRT import libraries (x64/arm32/arm64 msvcrt.dll) provide
mingw-w64 version of __p__wpgmptr() function defined via global variable
_wpgmptr.
Global variable _wpgmptr is available in all CRT libraries except UCRT.
Signed-off-by: Martin Storsjö <martin@martin.st>
Function __p__pgmptr() returns pointer to global variable _pgmptr and is
available since VC20, it is available also in UCRT, and also in x86 version
of OS system version msvcrt.dll.
For all other CRT import libraries (crtdll.dll, msvcrt10.dll and
x64/arm32/arm64 msvcrt.dll) provide mingw-w64 version of __p__pgmptr()
function defined via global variable _pgmptr.
Global variable _pgmptr is available in all CRT libraries except UCRT.
Signed-off-by: Martin Storsjö <martin@martin.st>
Function __p__wenviron() returns pointer to the first member of global
array _wenviron[] and is available since VC20, it is available also in
UCRT, and also in x86 version of OS system version msvcrt.dll.
For x64 version of msvcrt.dll provide mingw-w64 version of __p__wenviron()
function defined via global variable _wenviron[].
crtdll.dll and msvcrt10.dll do not provide _wenviron[] array and neither
__p__wenviron() function. Same applies for arm32 and arm64 versions of
msvcrt.dll.
Signed-off-by: Martin Storsjö <martin@martin.st>
Function __p__environ() returns pointer to the first member of global array
_environ[] and is available since VC20, it is available also in UCRT, and
also in x86 version of OS system version msvcrt.dll.
CRT libraries crtdll.dll, msvcrt10.dll and x64 msvcrt.dll do not provide
__p__environ() function but have exported _environ[] array. For thse import
libraries provide mingw-w64 version of __p__environ() function defined via
global variable _environ[].
Remaining CRT libraries arm32 and arm64 os system versions of msvcrt.dll do
not provide neither __p__environ() function, nor _environ[] array. So these
import libraries stay even without emulation.
Signed-off-by: Martin Storsjö <martin@martin.st>
Function __p___wargv() returns pointer to the first member of global array
__wargv[] and is available since VC20, it is available also in UCRT, and
also in x86 version of OS system version msvcrt.dll.
crtdll.dll and msvcrt10.dll do not provide __wargv[] array and
__wgetmainargs() function, so for these libraries is not provided neither
__p___wargv() function.
For remaining CRT import libraries (x64/arm32/arm64 msvcrt.dll) provide
mingw-w64 version of __p___wargv() function defined via global array
__wargv[].
Signed-off-by: Martin Storsjö <martin@martin.st>
Function __p___argc() returns pointer to global variable __argc and is
available since VC20, it is available also in UCRT, and also in x86 version
of OS system version msvcrt.dll.
For all other CRT import libraries (crtdll.dll, msvcrt10.dll and
x64/arm32/arm64 msvcrt.dll) provide mingw-w64 version of __p___argc()
function defined via global variable __argc.
Global variable __argc is available in all CRT libraries except UCRT.
Signed-off-by: Martin Storsjö <martin@martin.st>
Global variable _sys_nerr is present in every CRT library except UCRT.
Function __sys_nerr() is present since msvcr80.dll and returns pointer to
the global variable _sys_nerr. This function is not present in any
msvcrt.dll library version, but is present in UCRT library.
Same applies for global array _sys_errlist[] and function __sys_errlist()
which returns pointer to the first member of __sys_errlist[] array.
For all pre-msvcr80 CRT import libraries provides mingw-w64 functions
__sys_errlist() and __sys_nerr(). And change stdlib.h header file to
define _sys_nerr and _sys_errlist via __sys_errlist() and __sys_nerr()
functions. With this change, definitions will be compatible for all CRT
versions (crtdll, msvcrt, msvcr80+, UCRT).
Signed-off-by: Martin Storsjö <martin@martin.st>
_mbcasemap[] global array is available since Microsoft Visual C++ 5.0 SP1
version of msvcrt.dll for all architectures, and then also in new msvcr*
DLL libraries, and also in UCRT.
__p__mbcasemap() function is available in msvcrt.dll only for i386
architecture since Microsoft Visual C++ 5.0 SP1. For new msvcr* DLL
libraries, it is available also for non-i386 architecture.
So provide fallback implementation of __p__mbcasemap() function in non-i386
msvcrt.dll import libraries. And define _mbcasemap in header file via
__p__mbcasemap() function.
Signed-off-by: Martin Storsjö <martin@martin.st>
Global variable _mbctype[] is not available in UCRT and msvcrt10.dll. UCRT
instead provides __p__mbctype() function which returns pointer to the first
_mbctype array member. msvcrt10.dll does not have any replacement.
Function __p__mbctype() is present also in all msvcrt VC versions starting
from VC20 for all architectures. In OS system version of msvcrt.dll, this
function is present only for i386 architecture.
Therefore function __p__mbctype() is not present in: crtdll.dll,
msvcrt10.dll and x64, arm32 and arm64 versions of msvcrt.dll.
So for import libraries crtdll and x64, arm32 and arm64 versions of msvcrt
provides fallback implementation of __p__mbctype() function via _mbctype[].
Then change mbctype.h include file to define _mbctype via function call
__p__mbctype(). This change allows to use _mbctype with all CRT libraries,
including UCRT, except msvcrt10 (which does not have neither _mbctype[],
nor __p__mbctype()).
Signed-off-by: Martin Storsjö <martin@martin.st>
_wctype is global variable exported from DLL library, so mark it with
DATA and removes false-positive function stdcall @size decoration.
Signed-off-by: Martin Storsjö <martin@martin.st>
Global variable _pwctype is not available in UCRT. Instead UCRT has only
__pwctype_func() function which returns value of _pwctype variable.
Function __pwctype_func() is available also in msvcrt since VC70. For
previous i386 msvcrt versions there is a __p__pwctype() function which
returns pointer to the _pwctype variable.
Like for _pctype changes, add fallback versions of __pwctype_func() and
__p__pwctype() functions suitable for older CRT versions. And change
definition of _pwctype in header file from the global variable to macro
which calls __pwctype_func() function.
This change allows to use _pwctype with all CRT libraries, including UCRT.
Fix also type of _pwctype. In msvc its type is wctype_t and not unsigned
short. Note that wctype_t is just typedef for unsigned short, so this
should be just a cosmetic change to align with msvc.
Signed-off-by: Martin Storsjö <martin@martin.st>
__pctype_func is available in msvcrt since VC70. __p__pctype is available
in i386 msvcrt version since VC20. _pctype is available in all versions
except in UCRT.
Define fallback __pctype_func() function implementation via __p__pctype()
function. And define __p__pctype() via _pctype variable.
With this change every CRT import library provides __pctype_func()
function. So remove #ifdefs for _pctype declarations in header files and
unifies _pctype definitions between different CRT libraries.
Signed-off-by: Martin Storsjö <martin@martin.st>
Provide fallback ___mb_cur_max_func() implementation via __p___mb_cur_max()
function. __p___mb_cur_max() is available since VC20. For earlier version
import libraries provide fallback __p___mb_cur_max() implementation via
global variable __mb_cur_max.
With this change every CRT import library provides ___mb_cur_max_func()
function. So remove #ifdefs for __mb_cur_max declarations in header files.
Signed-off-by: Martin Storsjö <martin@martin.st>
Both functions __iob_func() and __p__iob() returns same constant value -
pointer to the first member of _iob[] array. Symbol for _iob[] array is
present in every msvcrt DLL library.
Function __p__iob() is provided by every i386 version of msvcrt DLL library
since VC20. But it is not available in any non-i386 version. Function
__iob_func() is provided by every version of msvcrt DLL library since VC70
for every architecture. __iob_func() is provided also by every X64 and ARM
versions of OS system version msvcrt.dll.
Note that UCRT does not provide neither __iob_func(), nor __p__iob()
function.
So for all msvcrt versions before VC70 define __iob_func symbol as an alias
to __p__iob symbol. And for versions before VC20 provide custom mingw-w64
implementation of __iob_func() function which returns pointer to the first
member of _iob[] array.
This change allows to remove #ifdef around _iob declaration in stdio.h and
wchar.h header files as now the __iob_func() function is provided by every
version of msvcrt import library.
Signed-off-by: Martin Storsjö <martin@martin.st>
Add once-guard to ensure that the file is processed only once.
Add arch-guard to ensure that DEF_<ARCH> is always defined to prevent an
issue that symbols defined via F32() macro completely disappeared and which
was fixed in previous change.
This change applied before the previous change cause compile errors.
Signed-off-by: Martin Storsjö <martin@martin.st>
Having -DDEF_<ARCH> is required by func.def.in which is used either
directly or indirectly by crt-aliases.def.in in all CRT def.in files.
Some symbols in crt-aliases.def.in are defined via F* macros and these
symbols are currently missing in versioned non-os msvcrt import libraries.
This change is fixing missing symbols in all CRT import libraries.
Signed-off-by: Martin Storsjö <martin@martin.st>
Currently __MINGW_IMP_SYMBOL symbols for aliased functions are defined as
a new plain global variable, just like for an original function.
GCC supports declaring global variable as an alias to other global
variable.
Change all aliases of import __MINGW_IMP_SYMBOL symbols via alias
attribute. This reduce memory usage as original symbol and aliased symbol
will share same global variable. Also it makes it clear that the aliased
import symbol is an alias to another import symbol.
Note that aliased symbol has to be declared with "extern" keyword even it
is not extern and gcc will emit this symbol (as described in documentation).
So for example:
int var_non_alias = 1;
int var_target = 2;
extern int __attribute__ ((alias ("var_target"))) var_alias;
Emits symbols:
SYMBOL TABLE:
[ 0](sec -2)(fl 0x00)(ty 0)(scl 103) (nx 1) 0x00000000 test.c
File
[ 2](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .text
AUX scnlen 0x0 nreloc 0 nlnno 0
[ 4](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .data
AUX scnlen 0x8 nreloc 0 nlnno 0
[ 6](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .bss
AUX scnlen 0x0 nreloc 0 nlnno 0
[ 8](sec 4)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .rdata$zzz
AUX scnlen 0x1e nreloc 0 nlnno 0
[ 10](sec 2)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 _var_non_alias
[ 11](sec 2)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000004 _var_target
[ 12](sec 2)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000004 _var_alias
Contents of section .data:
0000 01000000 02000000 ........
Signed-off-by: Martin Storsjö <martin@martin.st>
WinMain() entry point provided by the application is called by mingw-w64
startup code, more precisely by function main() from crtexewin.c file.
mingw-w64 startup code in file crtexewin.c calls _ismbblead() function.
Function _ismbblead() is not available in some versions of crtdll.dll
and is completely missing in msvcrt10.dll library.
Version of crtdll.dll library stored in its PE resource directory is not
meaningful as two different libraries, one with _ismbblead symbol and one
without _ismbblead symbol has same version.
Seems that there are MBCS aware crtdll.dll versions with _ismbblead symbol
and versions which are not MBCS aware without _ismbblead symbol.
All checked msvcrt10.dll files do not have _ismbblead symbols, so
msvcrt10.dll is not MBCS awre.
For msvcrt10.dll import library provides simple dummy _ismbblead() function
which always returns false to satisfy mingw-w64 startup file crtexewin.c.
For crtdll.dll import library provides _ismbblead() wrapper function and
disable the real function in the def file to prevent symbol conflicts. The
wrapper function via GetProcAddress() checks if the real crtdll.dll
provides _ismbblead() function. If real function exists then it is called.
If not then wrapper function returns false like the msvcrt10.dll one.
This fixes linking WinMain() entry point with msvcrt10.dll.
ld: /usr/local/lib/libmingw32.a(lib32_libmingw32_a-crtexewin.o): in function `main':
mingw-w64/mingw-w64-crt/crt/crtexewin.c:43: undefined reference to `_ismbblead'
collect2: error: ld returned 1 exit status
And fixes runtime error about missing _ismbblead symbol with some versions of crtdll.dll.
Entry Point Not Found
The procedure entry point _ismbblead could not be located in the
dynamic link library CRTDLL.dll.
Signed-off-by: Martin Storsjö <martin@martin.st>
API for __getmainargs() and __wgetmainargs() functions in msvcrt20.dll is
slightly different than in new msvcrt versions. In msvcrt20.dll these
functions return void and take new_mode parameter instead of the pointer to
the _startupinfo structure.
So for compatibility with mingw-w64 startup code, in msvcrt20 import
library rename exported __getmainargs/__wgetmainargs symbols to
__msvcrt20_getmainargs/__msvcrt20_wgetmainargs and provide mingw-w64
compatible wrappers named __getmainargs/__wgetmainargs around the
renamed symbols __msvcrt20_getmainargs/__msvcrt20_wgetmainargs.
See wine implementation for details:
https://gitlab.winehq.org/wine/wine/-/blob/wine-9.8/dlls/msvcrt20/msvcrt20.c7f1e74a97a
Signed-off-by: Martin Storsjö <martin@martin.st>
API for __getmainargs() function in msvcrt10.dll is same as __GetMainArgs()
function in crtdll.dll. It is slightly different than in any other msvcrt
versions. It returns void and does not the pointer to the _startupinfo
structure as a last argument.
So for compatibility with mingw-w64 startup code, in msvcrt10 import
library rename the real __getmainargs symbol to __GetMainArgs and use
mingw-w64 crtdll.dll's wrapper __getmainargs around the __GetMainArgs for
providing the compatible __getmainargs() function.
Signed-off-by: Martin Storsjö <martin@martin.st>
For 32-bit time_t (detected by _USE_32BIT_TIME_T), functions _fstat32(),
_fstat() and fstat() are same. So fstat() can be defined as simple alias
in def file.
Same applies for functions _fstat64i32(), _fstat() and fstat() when time_t
is 64-bit.
Simplify fstat() function, remove it from mingw-w64-crt/stdio/_fstat.c file
and provide it via aliases in api-ms-win-crt-filesystem-l1-1-0.def.in and
crt-aliases.def.in for all CRT import libraries.
This fixes FIXME issue described in the fstat.c.
This change also ensures that fstat and _fstat symbols would results in the
same function calls.
Signed-off-by: Martin Storsjö <martin@martin.st>
msvcrtd.dll is debug version of the Visual C++ 4.2, 5.x and 6.x msvcrt.dll
library and provides additional debugging functions.
Signed-off-by: Martin Storsjö <martin@martin.st>
msvcr40d.dll is debug version of the msvcrt40.dll and provides additional
debugging functions.
msvcr40d.def.in def file was generated by gendef from the original
msvcr40d.dll library version and modified with same changes (mostly
documentation) which were done to the msvcrt40.def.in def file.
Signed-off-by: Martin Storsjö <martin@martin.st>
getopt* functions receive also argv[0] argument. So use it for printing
program name instead of the global __argv[0] variable.
This avoids using and importing of the __argv[] DATA symbol from the linked
CRT library, as it is not needed.
Signed-off-by: Martin Storsjö <martin@martin.st>
Both symbols refers to global variable, not the function. So mark them with
DATA for all platforms. gendef detects that _mbcasemap is DATA for all I386
versions of msvcrt.dll (Visual C++ 5.0, 6.0, Win9x, 2000, XP, ... up to 10).
But gendef since Windows XP version of msvcrt.dll cannot autodetect that
_ctype is DATA symbol.
Signed-off-by: Martin Storsjö <martin@martin.st>
This file contains definitions of symbol aliases for any CRT library. It is
already used by msvcrt, crtdll and ucrt. So rename msvcrt-common.def.in to
crt-aliases.def.in as new name better match the purpose of the file.
Signed-off-by: Martin Storsjö <martin@martin.st>
Deduplicate aliases from msvcrt.def.in and ucrtbase.def.in to
def-include/msvcrt-common.def.in.
Note that powl alias was defined only in ucrtbase.def.in, so do not define
it for non-UCRT builds.
Signed-off-by: Martin Storsjö <martin@martin.st>
crtdll.dll library has some DATA symbols with _dll suffix.
Fix generating aliases for these symbols.
With this change also document why those symbols are not for UCRTBASE.
Signed-off-by: Martin Storsjö <martin@martin.st>
msvcrt versions 8.0 - 12.0 and UCRT do not have _utime symbol.
For these CRT versions (which do not have FIXED_SIZE_SYMBOLS) is later in
the file symbol _utime defined as an alias to _utime32 or _utime64 symbol.
So for these affected CRT versions define utime as an alias to _utime32 or
_utime64.
Signed-off-by: Martin Storsjö <martin@martin.st>
msvcrt versions 8.0 - 12.0 and UCRT do not have _strcmpi symbol.
For these CRT versions (which have NO_STRCMPI_ALIAS) is later in the file
symbol _strcmpi defined as an alias to _stricmp symbol.
So for these affected CRT versions define strcmpi as an alias to _stricmp.
Signed-off-by: Martin Storsjö <martin@martin.st>
Add a new helper macro ADD_UNDERSCORE_DATA for defining alias for
underscored DATA symbol.
Move symbol aliases into categories and document from which oldnames.lib
version they comes from or what is the reason for defining them (C99, POSIX
or GNU compatibility).
Document all symbols from the latest oldnames.lib library. Aliases were not
modified since Visual C++ 4.0. Missing symbol aliases were added as a
comment (and they can be enabled later by additional changes).
Signed-off-by: Martin Storsjö <martin@martin.st>
File msvcrt-common.def.in adds just symbol aliases, so include it in CRT
def files after having all symbols declared.
Note that some def files use macros from func.def.in file,
so include func.def.in at beginning of the file when needed.
Signed-off-by: Martin Storsjö <martin@martin.st>
Change library name to uppercase CRTDLL.dll and remove DATA keyword for all
time function symbols. This is how the original crtdll.dll library is defined.
Signed-off-by: Martin Storsjö <martin@martin.st>
Symbol _fstat64i32 is available in all 64-bit CRT import libraries as an
alias. For 32-bit CRT import libraries it is present as native import
symbol since msvcr80.
MinGW-w64 fallback implementation of _fstat64i32() function uses _fstat64()
call which in 32-bit versions is available since msvcr70 and also present
in the os system msvcrt.
Which means that for CRT versions msvcrt40 and older, the fallback
implementation does not work as it tries to call non-existing function.
So include MinGW-w64 fallback implementation only into 32-bit CRT
libraries: msvcrt-os, msvcr70, msvcr71. This removes duplicate symbols
in 64-bit versions.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some find, stat and time aliases are missing in UCRT def files:
api-ms-win-crt-filesystem-l1-1-0.def.in api-ms-win-crt-time-l1-1-0.def.in
They are already present in ucrtbase.def.in file after change from the
commit b463875615.
Add those aliases which are missing.
Signed-off-by: Martin Storsjö <martin@martin.st>
Symbols __p___argv, __p__acmdln, __p__commode, __p__fmode, and __p__wcmdln
are available in X64 version of msvcr80.dll. This was clarified and fixed
in commit e0426704cc. So remove duplicated
definitions of fallback functions.
Signed-off-by: Martin Storsjö <martin@martin.st>
Add 4 new macros FIXED_SIZE_SYMBOLS, NO_I64_FIXED_SIZE,
NO_FIXED_SIZE_64_ALIAS and NO_TIME_ALIAS to distinguish
between different crt versions.
This change adds new symbol aliases which were missing.
There is no symbol change or removal.
For reference here is list of changes between individual outputs from:
cpp -x c $FILE -Wp,-w -undef -P -Imingw-w64-crt/def-include -D$PLAT | sed -E 's/\s*;.*//' | LC_ALL=C sort -u
Signed-off-by: Martin Storsjö <martin@martin.st>
CRT header files ensures that time symbols without 32/64 suffixes are not
emitted. And linker always sees time symbols with explicit 32 or 64 suffix
name.
When CRT header files are not included then 32-bit MSVC compiler + linker
treats symbols without "64" suffix name as functions which use 32-bit
time_t, even for UCRT builds.
Do the same in mingw-w64, change 32-bit mode time symbol aliases which do
not have "64" in symbol name, to point to symbols which use 32-bit time_t
type.
With this change, time symbols in 32-bit mode have same meaning across all
CRT libraries provided by mingw-w64. For example symbol "time" points to
function "time" function which always takes 32-bit time_t.
This change fixes previous commits 42aa3325fc
and e37b315bc0
Signed-off-by: Martin Storsjö <martin@martin.st>
These symbols on 64 bit should resolve to _findfirst64i32/_findnext64i32
functions, like in other CRT libraries and header files.
The UCRT 32 bit aliases are kept as they were before (even if
they are known to be incorrect); they are corrected in a separate
later commit.
Signed-off-by: Martin Storsjö <martin@martin.st>
Symbol redirects in import libraries are defined by "==", while
"=" in def files is used to rename a symbol on export, while
linking a DLL (but that does not have any effect when creating
an import library with dlltool).
Signed-off-by: Martin Storsjö <martin@martin.st>
In the inline form of _snwprintf, we set
_CRT_INTERNAL_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION,
but in the non-inline version, we just called
vsnwprintf, which doesn't set that option.
Instead call __stdio_common_vswprintf directly, with the right
options.
The previous form stemmed from the original UCRT implementation
in bc6a874889.
Signed-off-by: Martin Storsjö <martin@martin.st>
def-include/msvcrt-common.def.in is included into every msvcr*.def.in file.
So move them all common __ms_* symbol aliases which removes definition
duplication.
msvcr* library before version 8.0 have symbols swprintf/vswprintf which
represents pre-C95 variants of these functions without maxlen argument.
Since version 8.0, symbols swprintf/vswprintf are not present anymore,
they were renamed and have have leading underscore.
Distinguish aliased symbol by a new PRE_C95_SWPRINTF macro in .def.in file.
Signed-off-by: Martin Storsjö <martin@martin.st>
These aliases are automatically added by including msvcrt-common.def.in
file into every msvcr*.def.in file.
Signed-off-by: Martin Storsjö <martin@martin.st>
Visual Studio .NET 2002 version of msvcr70.dll library (7.00.9466.0)
contains additional symbol __CxxCallUnwindVecDtor. Some older library
version (7.00.9210.0) does not have this symbol. Same set of symbols as in
the released .NET 2002 version is available also in Visual Studio .NET 2002
Service Pack 1 version of msvcr70.dll library (7.00.9955.0).
Signed-off-by: LIU Hao <lh_mouse@126.com>
CRT library functions _adj_fdiv_m* and _adj_fdivr_m* have custom calling
convention. These functions take two arguments. First argument is passed in
x87 st(0) register and second argument on the stack (either 4 or 8 bytes).
Function itself pops the stack (like stdcall convention) and return value
is stored in x87 st(0) register.
CL.EXE compiler when invoked with flag /QIfdiv generates calls to these
functions. Generated symbol names are without @SIZE suffix decoration.
So for compatibility with msvc, do not decorate these symbols with @SIZE
suffix (the suffix used for stdcall) in all def files.
Note that neither gcc, nor clang does not provide a way to define C
function declaration with this calling convention, so currently the only
way how to call these functions from the assembler or via gcc inline
assembly in C/C++. And therefore mingw-w64 does not provide declaration for
these functions in header files.
Signed-off-by: LIU Hao <lh_mouse@126.com>
_CxxThrowException, __CxxLongjmpUnwind, _adj_fdiv_*, _adj_fdivr_* and
_seh_longjmp_unwind are present also in Windows NT-based OS system versions
of msvcrt40.dll as redirects to msvcrt.dll library.
gendef does not recognize stdcall convention by default for such redirected
symbols and shows them without @SIZE. Fix it.
This effectively reverts commit 2455c14750.
Signed-off-by: LIU Hao <lh_mouse@126.com>
These functions do not return and gendef false positively detected stdcall
calling convention for them on Windows XP and SP1 binaries. Remove wrong
comment.
Signed-off-by: LIU Hao <lh_mouse@126.com>
I386 symbols __CxxLongjmpUnwind, _adj_fdiv_m*, _adj_fdivr_m* and
_seh_longjmp_unwind use stdcall convention, so add @SIZE suffix
for them into I386 version of def file for msvcr80.dll.
(_adj_fdiv* actually aren't stdcall but a custom calling convention;
these will be fixed further in a later upcoming commit.)
Fix symbol names in lib32/msvcr80.def.in file.
Signed-off-by: Martin Storsjö <martin@martin.st>
Symbols __CxxFrameHandler2, _freea_s, _get_pgmptr and _get_wpgmptr are not
present in Windows RT 8.0 and neither in 8.1 versions of msvcrt.dll
library. So mark them as X86-only.
And additional symbol __jump_unwind is present in Windows RT 8.0 and 8.1,
so put it into Windows 8 section as ARM-only.
Also update comment about ARM32 C++ symbols, they fully matches Windows RT
8.0 and 8.1 versions.
Inspected Windows RT 8.0 msvcrt.dll ARM32 has version string 7.0.9200.16384.
And Windows RT 8.1 msvcrt.dll ARM32 has version string 7.0.9468.0.
Signed-off-by: Martin Storsjö <martin@martin.st>
__lc_clike and _mbcasemap symbols are DATA in all msvcr*.dll libraries,
including I386 variant of msvcr80.dll. So fix lib32/msvcr80.def.in file.
Signed-off-by: Martin Storsjö <martin@martin.st>
Symbols __p__fileinfo, _ctype, _fileinfo, _ftime, _futime, _mbscat,
_mbscpy, _mbsdup, _strcmpi, _utime, _wutime, difftime, swprintf, vswprintf,
__buffer_overrun, __security_error_handler, __set_buffer_overrun_handler,
_set_security_error_handler and _wctype are not present in any variant of
msvcr80.dll library. So they are not usable in the current form.
Symbols _ftime, _futime, _utime, _wutime, difftime and _strcmpi can be
defined as aliases to other existing symbols. For I386 time functions is
used 32-bit time_t, for X64 time functions is used 64-bit time_t, like in
other msvcr*.dll libraries.
Functions swprintf() and vswprintf() have already replacement inline
variants defined in header file <swprintf.inl>.
Functions __ms_swprintf() and __ms_vswprintf() are defined without size_t
argument, which corresponds to msvcr80.dll's _swprintf() and _vswprintf()
functions. So add appropriate aliases.
But remaining symbols __p__fileinfo, _ctype, _fileinfo, _mbscat, _mbscpy,
_mbsdup and _wctype do not have replacement, so completely remove them from
msvcr80.def.in files.
Also I386 symbols __buffer_overrun, __security_error_handler,
__set_buffer_overrun_handler and _set_security_error_handler do not have
any replacement, so remove them too.
Signed-off-by: Martin Storsjö <martin@martin.st>
All symbols are extracted from the latest version of msvcr80.dll library
which is Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package
MFC Security Update available for download at page:
https://www.microsoft.com/download/details.aspx?id=26347
Signed-off-by: Martin Storsjö <martin@martin.st>
It looks like that lib64/msvcr80.def.in file contains X64 C++ symbols not
from the msvcr80.dll library but from the Windows XP x64 msvcrt.dll
library. X64 version of msvcrt.dll and msvcr80.dll have different C++
symbols but relatively same set of C symbols.
Replace incorrect X64 C++ symbols in lib64/msvcr80.def.in file by the
correct symbols from Visual C++ 2005 SP1 X64 msvcr80.dll library.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some of these functions, such as `ConvertAtJobsToTasks`, are exported with both
undecorated and decorated names, respectively, `ConvertAtJobsToTasks` and
`_ConvertAtJobsToTasks@0`. The decorated names are almost useless for C code
anyway and are removed.
Some other stdcall functions, such as `__fls_getvalue`, are only exported with
decorated names. A new macro `DECORATED_EXPORT()` is introduced for them.
This fixes errors like
#include <stdio.h>
#include <windows.h>
/* This was `__stdcall` in X3DAUDIO1_2.DLL, and changed to `__cdecl` later. */
__declspec(dllimport) void __stdcall X3DAudioCalculate(void*, void*, void*, UINT, void*);
int main(void)
{
printf("X3DAudioCalculate = %p\n", (void*)(INT_PTR) X3DAudioCalculate);
}
which used to result in
test.c:(.text+0xf): undefined reference to `_imp__X3DAudioCalculate@20'
Signed-off-by: LIU Hao <lh_mouse@126.com>
Symbols _swprintf and _vswprintf were added in Windows Vista and have same
meaning as symbols without leading underscore in msvcrt.dll. These symbols
(both with and without leading underscore) differs from C99 variant as they
do not take maxlen parameter.
For compatibility with pre-Vista systems, which are x86-only, define
_swprintf and _vswprintf symbols on I386 and X64 as aliases to swprintf and
vswprintf.
Signed-off-by: LIU Hao <lh_mouse@126.com>
Commit c52f1eb099 incorectly stated that
_strtoi64 and _strtoui64 symbols are available since the first release of
msvcrt.dll library (part of MS Visual C++ 4.2).
But only the symbol _atoi64 mentioned in that commit is available since
the first msvcrt.dll release.
Symbols _strtoi64 and _strtoui64 (as can be now seen in msvcrt.def.in
comments) were introduced in Windows XP version of msvcrt.dll.
So for I386 msvcrt.dll builds, use mingw-w64 implementation of _strtoi64
and _strtoui64 functions, like it was before that mentioned commit.
The mentioned commit broke support for Windows NT 4.0 and Windows 2000 as
msvcrt!_strtoi64 and msvcrt!_strtoui64 symbols are not available on these
systems.
This issue was reported by Marius Negruțiu into mingw-w64 bug tracker:
https://sourceforge.net/p/mingw-w64/bugs/966/
Signed-off-by: LIU Hao <lh_mouse@126.com>
For non-msvcrtos builds are global variables __MINGW_IMP_SYMBOL(_scprintf)
__MINGW_IMP_SYMBOL(_vscprintf) not changing, they are constant.
So define _scprintf and _vscprintf functions as direct alias to
emu_scprintf and emu_vscprintf functions instead of via indirect
unconditional jump or function call.
This also simplifies _scprintf definition for non-msvcrtos builds as it
reduces usage of inline assembly code.
There is no change for msvcrtos build.
Signed-off-by: LIU Hao <lh_mouse@126.com>
Windows XP x64 does not provide 32-bit time functions. Those are provided
on X64 systems since Windows Vista x64.
Main function symbols (those without suffixes) are 64-bit on all Windows
x64 systems.
So remove aliasing of X64 "time" symbol to "_time64" symbol as it is not
needed. This removes also aliasing on ARM32, which makes "time" symbol on
ARM32 to be 32-bit.
Symbol "_difftime64" was added in Windows Vista. So for compatibility with
Windows XP x64, define "_difftime64" symbol as alias to "difftime". Both
symbols have same functionality.
And export _ctime32, _mktime32, _time32 and _wctime32 symbols also on X64
version of msvcrt.dll as they are available since Windows Vista for both
I386 and X64. Note that they are not available on Windows XP x64, but there
is no reason to not export them (because mingw-w64 crt does not provide any
fallback replacement implementation).
Signed-off-by: Martin Storsjö <martin@martin.st>
Symbol __CxxCallUnwindDelDtor is not available in any X64 version of
msvcrt.dll library. So do not export it on X64.
Fixes commit 2924b57339.
Signed-off-by: Martin Storsjö <martin@martin.st>
Symbols _getdllprocaddr, _heapadd, _heapused, _loaddll and _unloaddll are
available also in Windows XP x64 but were removed in Windows Vista x64 and
not present in any later Windows x64 version. So do not export these
symbols for X64.
Signed-off-by: Martin Storsjö <martin@martin.st>
Library msvcrt.dll was used by Visual C++ versions 4.2 - 6.0 and is also
part of the Windows system starting with NT 4.0 and 98.
Currently the file msvcrt.def.in contains mix of all symbols in semi
alphabetical order, with ad-hoc symbol aliases which some are not exported
by any msvcrt.dll version (but needed for mingw-w64).
Cleanup symbol definitions, reorder them into chronological order according
to released msvcrt.dll versions and add exhausting comments explaining from
which msvcrt.dll version is symbol present and also if it is being replaced
by other symbol at linking time for backward version compatibility reasons.
If there is a comment "replaced by" at a symbol line, it means that the
symbol is present since particular msvcrt.dll version, but mingw-w64 is
unconditionally replacing it by its own implementation.
If there is a comment "provided by" at a symbol line, it means that the
symbol for some architecture is not present in any version of msvcrt.dll
and mingw-w64 is providing own implementation.
In future this change allows to easily figure out if specific operating
system or Visual C++ version has support for particular function symbol
and if mingw-w64 is going to use that symbol or is replacing it by its own
implementation.
Chronological order of msvcrt.dll versions in which were changes is:
- Visual C++ 4.2 / Windows NT 4.0
- Visual C++ 5.0 SP1 / Windows 98 First Edition
- Visual C++ 6.0 / Windows 98 Second Edition
- Windows 2000 / Windows ME
- Windows 2000 SP4 (*)
- Windows XP
- Windows XP SP3
- Windows Server 2003
- Windows Server 2003 SP1 / Windows XP x64
- Windows Vista
- Windows 8
- Windows 8.1
(*) there is a small exception, new Windows 2000 SP4 symbols are not in
Windows XP until SP3.
msvcrt.def.in currently does not define symbols which were introduced in
Windows 10 (or new) version of msvcrt.dll. There is a TODO comment for it.
Also there is a TODO comment for future cleanup/documentation of ARM
symbols, as this change targets only I386 and X64 versions of msvcrt.dll.
This change as is does not introduce or remove any existing symbol in
msvcrt.def.in. It can be verified by comparing output of the following
command. Replace $PLAT with one of: DEF_I386 DEF_X64 DEF_ARM32 DEF_ARM64
cpp -x c mingw-w64-crt/lib-common/msvcrt.def.in -Wp,-w -undef -P -Imingw-w64-crt/def-include -D$PLAT | sed -E 's/\s*;.*//' | LC_ALL=C sort -u
Signed-off-by: Martin Storsjö <martin@martin.st>
For I386 and X64 they are present in msvcrt.dll since Windows Vista.
And Martin Storsjö pointed that ARM64 version of msvcrt.dll also contains
them.
Signed-off-by: Martin Storsjö <martin@martin.st>
dli.szDll is of LPCSTR type, which is always const char* (and not wchar_t*).
So instead of LoadLibrary() (which may take wchar_t* if _UNICODE macro is
defined by compiler) use LoadLibraryA() (which always takes char*).
Signed-off-by: Martin Storsjö <martin@martin.st>
Symbols __buffer_overrun, __lc_clike, __security_error_handler,
__set_buffer_overrun_handler, _CRT_RTC_INIT, _set_security_error_handler
and _set_purecall_handler are not available in any examined I386 version of
msvcrt.dll (up to Windows 10).
Reason why there are defined in lib-common/msvcrt.def.in is probably
because in commit 0360917119 they were moved
from file lib32/msvcrt.def.in. And originally in file lib32/msvcrt.def.in
all these symbols were after the comment "; msvcr70.dll and later". Which
could explain that these symbols are in msvcr70.dll library, but not in OS
system version of msvcrt.dll library.
Signed-off-by: Martin Storsjö <martin@martin.st>
Symbol wcsnlen was first introduced in Windows Vista version of msvcrt.dll
and mingw-w64 already provides replacement implementation in libmingwex. So
always use the replacement implementation on I386 and X64 and do not export
it. Also remove DATA keyword and use it in the same way as other wc*
symbols like wcsrtombs.
Signed-off-by: Martin Storsjö <martin@martin.st>
It is available in Windows XP x64, but was removed in Windows Vista x64.
So disable its usage for X64.
Signed-off-by: Martin Storsjö <martin@martin.st>
I386 symbols __CxxLongjmpUnwind, _adj_fdiv_m*, _adj_fdivr_m* and
_seh_longjmp_unwind have @8 size suffix in all msvcrt.dll versions,
including original MSVC 4.2, 5.0, 6.0 and also in Windows 98, ME and also
in all NT versions (4.0, 2000, XP up to 10).
Without @SIZE suffix are these symbols only in I386 NT versions of
msvcrt40.dll library.
Signed-off-by: Martin Storsjö <martin@martin.st>
In msvcrt.def.in file are already defined mangled C++ symbols for X64 and
ARM32 versions of msvcrt.dll, so add also them for I386 version.
These symbols are present in Visual C++ 4.2 version of msvcrt.dll and same
set of symbols are in Visual C++ 5.0 and 6.0 versions.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some symbols from original Microsoft Visual C++ 4.0 msvcrt40.dll library
are not available in Windows NT-based OS systems versions. Disable these
symbol exports as they are not usable on any recent system.
Signed-off-by: Martin Storsjö <martin@martin.st>
The original msvcrt40.dll version from Visual C++ 4.0 does not contain some
symbols, which are present in the version from Visual C++ 4.1 Upgrade. Also
Win32s version of msvcrt40.dll from Visual C++ 4.0 does not contain all
symbols as full version. Follow up Visual C++ 4.2 Upgrade switches from
msvcrt40.dll to msvcrt.dll library, so it is out of the msvcrt40.def.in
scope. Windows 9x OS system versions of msvcrt40.dll contains same set of
symbols as full version from Visual C++ 4.1 Upgrade. But all Windows NT OS
system versions of msvcrt40.dll misses some symbols.
Signed-off-by: Martin Storsjö <martin@martin.st>
The original msvcrt20.dll version from Visual C++ 2.0 does not contain some
symbols, which are present in the version from Visual C++ 2.1 Upgrade. Also
Win32s version of msvcrt20.dll from Visual C++ 2.0 does not contain all
symbols as full version. Follow up Visual C++ 2.2 Upgrade version have not
introduced any new symbol. Windows OS system versions of msvcrt20.dll
contains same set of symbols as full version from Visual C++ 2.1 Upgrade.
Signed-off-by: Martin Storsjö <martin@martin.st>
When using mkstemp, there is no guarantee nor expectation that the
caller has called srand() with an unique seed. Therefore, in practice,
many users of mkstemp run with the same seed (unseeded).
Normally, the implementation of mkstemp does handle collisions just
fine, by continuing iteration and trying another pseudorandom file
name, until finding a unique name. (If there are collisions and both
processes run unseeded, both will always try the same sequence though.)
However in some rare cases of collisions, _sopen can return an error,
setting errno to e.g. EACCES. In this case, our implementation of
mkstemp stops iterating and returns the error to the caller. (This is,
in general, the right decision; if the user does not have write
permission in the expected directory, we should abort, not keep retrying
infinitely.)
Use rand_s() to get properly unique random numbers here, without
relying on the caller seeding the random number generator.
Older versions of msvcrt.dll do lack rand_s, but in libmsvcrt-os.a,
we provide rand_s as a wrapper that tries to locate rand_s at runtime,
and tries to do a fallback implementation otherwise. If all the
fallbacks within our rand_s() wrapper fail, fall back on plain rand(),
which is no worse than what we had before.
The issue with collisions can be reproduced with these commands (run
them all in without long pauses):
for n in {1..15000}; do rm -f lib/libLLVMAVRAsmParser.a && \
ar qc lib/libLLVMAVRAsmParser.a lib/Target/AVR/AsmParser/CMakeFiles/LLVMAVRAsmParser.dir/AVRAsmParser.cpp.obj && \
ranlib.exe lib/libLLVMAVRAsmParser.a; done &
for n in {1..15000}; do rm -f lib/libLLVMSparcCodeGen.a && \
ar qc lib/libLLVMSparcCodeGen.a lib/Target/Sparc/CMakeFiles/LLVMSparcCodeGen.dir/*.obj && \
ranlib.exe lib/libLLVMSparcCodeGen.a; done
echo "done"
fg
Before the patch it will fail with an error: "ranlib.exe: could not
create temporary file whilst writing archive: no more archived files"
or "...: Permission denied".
The changes in this patch were proposed by Josh Stone on Rust's Zulip
server and I was asked to forward it.
Co-Authored-By: Josh Stone <jistone@redhat.com>
Signed-off-by: Mateusz Mikuła <mati865@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
MSVC does provide this function without an underscore prefix (via
the oldnames library) just like a number of other functions.
In mingw-w64 headers, we already provide a declaration of this
function, just like many others, but it was missing from the
import libraries.
Provide it as an alias, just like we do for many other similar
functions that only exist with a leading underscore in the runtime
DLLs.
Signed-off-by: Martin Storsjö <martin@martin.st>
The ADD_UNDERSCORE macro adds an alias, without a leading underscore,
for an existing export with a leading underscore.
For some functions, we're not providing these aliases, e.g. because
those symbols are defined by other means, e.g. in source files (such
as CRT_fp10.c and CRT_fp8.c).
This patch improves the style of those cases, which are listed as
commented out instances of the ADD_UNDERSCORE macro.
Signed-off-by: Martin Storsjö <martin@martin.st>
* Include C++ mangled symbols
* Include Windows NT 3.51+ symbols
* Extend comment about different versions
* Update list of symbols which do not have prototypes yet
Signed-off-by: Martin Storsjö <martin@martin.st>
Header file time.h already redirects function call gmtime() to _gmtime32().
So if object file compiled with time.h is linked with e.g. libmsvcrt40.a
import library then it is needed to add redirection from _gmtime32 symbol
to gmtime symbol into libmsvcrt40.a library to ensure that application
would use gmtime symbol, because msvcrt40.dll does not provide _gmtime32.
Same applies for all other 32-bit time symbols.
Signed-off-by: Martin Storsjö <martin@martin.st>
Trying to use or link DllMain symbol from some random system DLL library is
in most cases a mistake. So hide all DllMain definitions from all def files.
Signed-off-by: Martin Storsjö <martin@martin.st>
If application does not specify its own DllEntryPoint function then the
default DllEntryPoint provided by libmingwex library should be used. And
not from some random system DLL library.
Signed-off-by: Martin Storsjö <martin@martin.st>
The variable is only used within mingw_pformat.c, increasing
strictness in newer versions of GCC has turned this into an
error despite both integer widths are 32bit.
Correct so it matches the __gdtoa prototype declaration.
Signed-off-by: Jonathan Yong <10walls@gmail.com>
