uf=12 ret=9
Which is correct now.
Would you consider fixing snprintf() in mingw-w64?
Similarly also vsnprintf() can be fixed:
#define vsnprintf(str, size, format, ap) ( (((size_t)(size) > 0) ?
(_vsnprintf((str), (size), (format), (ap)), ((char *)str)[(size_t)(size)-1] =
0, 0) : 0), _vscprin
resending this email again.
Btw, if macro is not suitable then it is possible to write normal
snprintf function which would call _snprintf() and _scprintf() as in
that macro.
On Friday 03 May 2019 10:39:46 Pali Rohár wrote:
> Hello!
>
> snprintf() function in mingw-w64 is brok
()
wrapper is needed.
PS: Please CC me as I'm not subscribed to list.
On Sunday 16 February 2020 22:03:21 Pali Rohár wrote:
> Hello! Year ago I sent this email about snprintf() problem in mingw-w64
> but I have not received any response yet.
>
> For one week I tried to contact mingw-w64 devel
C99 and C++11 standards requires printf ll modifier for long long type but
it does not work in WinXP system msvcrt.dll. It requires at least library
msvcr80.dll.
So when gcc is invoked with --std=c99 (or new) or --std=c++11 (or new) ansi
stdio macro needs to be enabled for printf ll modifier
Trying to link application with msvcr80.dll instead of msvcrt.dll (e.g. by
replacing -lmsvcrt by -lmsvcr80 in gcc spec file) results in following
linker error:
.../lib/crt2.o: in function `_tmainCRTStartup':
.../mingw-w64-crt/crt/crtexe.c:290: undefined reference to
nition error should not be triggered as C99
allows you to have one inline and one non-inline definition of the same
function.
And I think after adding "inline" for function definition in header
file, patch which Liu Hao posted should not be needed.
--
Pali Rohár
pali.ro...@gmail.com
On Tuesday 28 April 2020 22:02:35 Liu Hao wrote:
> 在 2020/4/28 15:21, Pali Rohár 写道:
> > Trying to link application with msvcr80.dll instead of msvcrt.dll (e.g. by
> > replacing -lmsvcrt by -lmsvcr80 in gcc spec file) results in following
> > linker error:
> >
>
On Thursday 30 April 2020 10:17:55 Liu Hao wrote:
> 在 2020/4/30 2:31, Pali Rohár 写道:
> > On Wednesday 29 April 2020 22:20:57 Liu Hao wrote:
> >
> > The application failed to initialize properly (0xc142). Click OK to
> > terminate application.
> &g
On Thursday 30 April 2020 08:17:04 Martin Storsjö wrote:
> On Wed, 29 Apr 2020, Liu Hao wrote:
>
> > 在 2020/4/28 15:22, Pali Rohár 写道:
> > > C99 and C++11 standards requires printf ll modifier for long long type but
> > > it does not work in WinXP system msvcrt.dll
On Wednesday 29 April 2020 22:20:57 Liu Hao wrote:
> 在 2020/4/28 23:47, Pali Rohár 写道:
> >
> > They really exist in my tested msvcr80.dll file!
> >
> > I thought that if symbols are missing in mingw def files then functions
> > are unimplemented. But it looks
On Wednesday 29 April 2020 22:20:57 Liu Hao wrote:
> 在 2020/4/28 23:47, Pali Rohár 写道:
> >
> > They really exist in my tested msvcr80.dll file!
> >
> > I thought that if symbols are missing in mingw def files then functions
> > are unimplemented. But it looks
On Thursday 30 April 2020 17:22:52 Liu Hao wrote:
> 在 2020/4/30 17:14, Pali Rohár 写道:
> >
> > So problem is only with 80, not 90.
> >
> > Anyway, that error message is issued by msvcr80.dll library itself, so I
> > think it could be possible to do some
On Thursday 30 April 2020 17:13:05 Liu Hao wrote:
> 在 2020/4/30 16:43, Pali Rohár 写道:
> >
> > I think there is another problem:
> >
> > Function wcstof() which is in mingw-w64-headers/crt/stdlib.h should be
> > marked as "inline". Otherwise there c
On Friday 21 February 2020 17:22:13 Pali Rohár wrote:
> On Friday 21 February 2020 18:17:37 Liu Hao wrote:
> > 在 2020/2/21 2:27, Pali Rohár 写道:
> > > Hello! Based on raymod2 suggestion on IRC, I prepared full patch and
> > > tested it that snprintf() and
This fixes commit bfd33f6c0ec5e652cc9911857dd1492ece8d8383. _UCRT does not
have to be defined yet (it is defined after including _mingw.h), but
__MSVCRT_VERSION__ at this stage is always defined (few lines above).
---
mingw-w64-headers/crt/_mingw.h.in | 4 ++--
1 file changed, 2 insertions(+), 2
On Thursday 30 April 2020 11:29:47 Pali Rohár wrote:
> On Thursday 30 April 2020 17:22:52 Liu Hao wrote:
> > 在 2020/4/30 17:14, Pali Rohár 写道:
> > >
> > > So problem is only with 80, not 90.
> > >
> > > Anyway, that error message is issued by msvcr80.
On Wednesday 29 December 2021 22:35:08 LIU Hao wrote:
> 在 2021-12-23 22:20, Pali Rohár 写道:
> > Original MSVC 6.0 msvcrt.dll library does not provide _vscprintf()
> > function. Therefore usage of snprintf() with this DLL library cause
> > application crash. Add simple fa
On Friday 31 December 2021 00:30:37 Jacek Caban wrote:
> On 12/29/21 16:52, Martin Storsjö wrote:
> > On Wed, 29 Dec 2021, LIU Hao wrote:
> >
> > > 在 2021-12-23 22:20, Pali Rohár 写道:
> > > > Original MSVC 6.0 msvcrt.dll library does not provide _vscprintf
Original MSVC 6.0 msvcrt.dll library does not provide _vscprintf()
function. Therefore usage of snprintf() with this DLL library cause
application crash. Add simple fallback implementation of _vscprintf() just
for __ms_vsnprintf() to allow usage of snprintf() function also when using
original
Functions __ms_snprintf() and __ms_vsnprintf() contains same logic and code
around _vscprintf() and _vsnprintf() wrappers. Remove duplicated code from
__ms_snprintf() and redirects __ms_snprintf() to __ms_vsnprintf().
---
mingw-w64-crt/stdio/snprintf.c | 22 +-
1 file changed,
Import library libcrtdll.a (for crtdll.dll runtime library) compiled during
mingw-w64 build process is currently broken and cannot be used for linking
executable applications.
Trying to do it results in following linker errors:
/usr/bin/i686-w64-mingw32-ld: .../i686-w64-mingw32/lib/crt2.o: in
Original MSVC 6.0 msvcrt.dll library does not provide _scprintf()
function. Add fallback _scprintf() implementation like for _vscprintf().
---
mingw-w64-crt/Makefile.am | 1 +
mingw-w64-crt/lib-common/msvcrt.def.in | 4 ++
mingw-w64-crt/misc/_scprintf.c | 52
Original MSVC 6.0 msvcrt.dll library does not provide _vscprintf()
function. MinGW-w64 __ms_snprintf() and __ms_vsnprintf() implementations
call _vscprintf() function. So include fallback _vscprintf() implementation
into MinGW-w64 crt code to allow applications to use snprintf() with
original MSVC
On Tuesday 11 January 2022 11:40:45 Martin Storsjö wrote:
> On Mon, 10 Jan 2022, LIU Hao wrote:
>
> > 在 2022-01-01 05:54, Pali Rohár 写道:
> > >
> > > Well, if you want from me any improvements in this patch, I can do it.
> > > Just let me know what is neede
On Thursday 13 January 2022 23:22:10 Martin Storsjö wrote:
> On Wed, 12 Jan 2022, Pali Rohár wrote:
>
> > Original MSVC 6.0 msvcrt.dll library does not provide _vscprintf()
> > function. MinGW-w64 __ms_snprintf() and __ms_vsnprintf() implementations
> > call _vscprint
On Friday 14 January 2022 01:36:10 Pali Rohár wrote:
> On Thursday 13 January 2022 23:22:10 Martin Storsjö wrote:
> > On Wed, 12 Jan 2022, Pali Rohár wrote:
> >
> > > Original MSVC 6.0 msvcrt.dll library does not provide _vscprintf()
> > > function. MinGW-w64 _
Currently v*scanf functions are broken and crash when are called with more
than 30 arguments in va_list. This is because va_list v*scanf functions are
redirected to variadic *scanf functions and this redirect implemented in
scanf.S file has fixed limit for 30 arguments.
Number of arguments for
Currently macro __LIBMSVCRT__ is defined when building any libmsvcr*.a
import library. But header file msvcrt.h contains inline function
__mingw_get_msvcrt_handle() which should be used only from import library
for runtime msvcrt.dll (and not for any other runtime msvcr*.dll) as code
from that
Object files in archive libcrtdll_extra.a (which are linked into import
library for crtdll.dll) cannot use msvcrt.h as it tries to load symbols at
runtime from msvcrt.dll using GetProcAddress().
So avoid using msvcrt.h and __mingw_get_msvcrt_handle() in crtdll.dll
runtime and directly use
---
mingw-w64-headers/crt/stdio.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index d96f5c96fc65..dd0f324db2be 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -721,6 +721,7 @@ int vsnprintf
---
mingw-w64-headers/crt/stdio.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index dd0f324db2be..76fffa177b10 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -732,6 +732,7 @@ int vsnprintf
When gcc was compiled with crtdll config then it links binaries with
-lcrtdll instead of -lmsvcrt and predefines macro __CRTDLL__.
So when __MSVCRT_VERSION__ was not manually set and gcc is not going to use
-lmsvcrt then set __MSVCRT_VERSION__ to 0x00 to indicate that msvcrt.dll is
not used.
---
MinGW-w64 (v)snprintf() implementation uses windows functions _(v)snprintf()
and _(v)scprintf(). Runtime library crtdll.dll provides only _(v)snprintf(),
so include MinGW-w64 emulation of _(v)scprintf() functions into libcrtdll.a
import library.
As header file and __mingw_get_msvcrt_handle()
crtdll.dll runtime does not suppport 64-bit printf/scanf modifiers. So when
targeting crtdll.dll runtime and not using MinGW-w64 stdio functions then
do not define any 64-bit modifier in inttypes.h header file.
crtdll.dll does not interpret %I64d modifier and does not read next
argument from
2003 and it
supports loadable plugins, then new plugin may be developed and compiled
by mingw-w64 with linking to msvcr71.dll (Visual Studio 2003 CRT) via
libmsvcr71.a import library, which is build by this patch series.
Pali Rohár (7):
crt: Move implementation of __initenv and __winitenv
This is CRT runtime library for Visual C++ 1.x (MSVC 8.00). It should be
distributed as a part of the application which use it. msvcrt10.def file
was generated from the original redistributable version of this library.
---
mingw-w64-crt/Makefile.am| 25 +-
These are CRT runtime libraries for Visual Studio 2002 and 2003. These
libraries need to be installed separately via redistributable packages.
---
mingw-w64-crt/Makefile.am | 22 +-
mingw-w64-crt/lib32/msvcr70.def | 899
mingw-w64-crt/lib32/msvcr70.mri |
This is CRT runtime library for Visual C++ 4.0 (MSVC 10.00) and 4.1 (10.10).
It is present in every 32-bit x86 Windows as a system library.
msvcrt40.def file was generated from the original redistributable version
of Visual C++ 4.1 library.
---
mingw-w64-crt/Makefile.am| 18 +-
This is CRT runtime library for Visual C++ 2.0 (MSVC 9.00) and is present
in every 32-bit x86 Windows as a system library.
---
mingw-w64-crt/Makefile.am| 20 +-
mingw-w64-crt/lib32/msvcrt20.def | 1570 ++
mingw-w64-crt/lib32/msvcrt20.mri |6 +
3 files
It would be used also in followup changes.
---
mingw-w64-crt/Makefile.am | 1 +
mingw-w64-crt/crt/crtdll_compat.c | 5 -
mingw-w64-crt/misc/dummy__setusermatherr.c | 11 +++
3 files changed, 12 insertions(+), 5 deletions(-)
create mode 100644
It would be used also in followup changes.
---
mingw-w64-crt/Makefile.am | 1 +
mingw-w64-crt/crt/crtdll_compat.c | 6 --
mingw-w64-crt/stdio/mingw_dummy__lock.c | 12
3 files changed, 13 insertions(+), 6 deletions(-)
create mode 100644
crtdll.dll and ucrt needs same implementation of __initenv and __winitenv
symbols. Deduplicate code and move it into a new misc/__initenv.c file.
---
mingw-w64-crt/Makefile.am | 2 ++
mingw-w64-crt/crt/crtdll_compat.c | 6 --
mingw-w64-crt/crt/ucrtbase_compat.c | 5 -
x86_64-w64-mingw32-gcc throws following -Wsign-compare warning when
compiling 64-bit NT kernel drivers which include ddk/ntddk.h file:
ddk/wdm.h: In function ‘RtlExtendedMagicDivide’:
ddk/wdm.h:9531:32: warning: operand of ?: changes signedness from ‘long long
int’ to ‘ULONG64’ {aka ‘long
On Thursday 10 March 2022 15:01:20 Martin Storsjö wrote:
> Hi,
>
> On Mon, 7 Mar 2022, Pali Rohár wrote:
>
> > There are more variants of msvcrt runtime libraries and mingw-w64
> > currently does not build import library for each variant. Some variants
> > are ava
When assigning function pointer to variable, both function and variable
should have same signature. Fix it.
---
mingw-w64-crt/stdio/ucrt__vscprintf.c | 2 +-
mingw-w64-crt/stdio/ucrt_snprintf.c | 2 +-
mingw-w64-crt/stdio/ucrt_vsnprintf.c | 2 +-
3 files changed, 3 insertions(+), 3
Redirect (v)snprintf() call with n==0 arg directly to _(v)scprintf() call
at compile time. With this change gcc can optimize out __ms_(v)snprintf()
call even when MinGW-w64 runtime was not compiled with LTO.
---
mingw-w64-headers/crt/stdio.h | 14 ++
1 file changed, 10 insertions(+),
Object files in archive libcrtdll_extra.a (which are linked into import
library for crtdll.dll) cannot use msvcrt.h as it uses msvcrt.dll runtime
library.
So avoid using msvcrt.h and __mingw_get_msvcrt_handle() in crtdll.dll
runtime and directly use "setlocale_codepage_hack" implementation.
This
Currently macro __LIBMSVCRT__ is defined when building any libmsvcr*.a
import library. But header file msvcrt.h contains inline function
__mingw_get_msvcrt_handle() which should be used only from import library
for runtime msvcrt.dll (and not for any other runtime msvcr*.dll) as code
from that
On Thursday 10 March 2022 22:51:12 Pali Rohár wrote:
> On Thursday 10 March 2022 15:01:20 Martin Storsjö wrote:
> > Hi,
> >
> > On Mon, 7 Mar 2022, Pali Rohár wrote:
> >
> > > There are more variants of msvcrt runtime libraries and mingw-w64
> > > cur
---
mingw-w64-crt/crt/crtdll_compat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-crt/crt/crtdll_compat.c
b/mingw-w64-crt/crt/crtdll_compat.c
index 0f0b8d4820da..7ab3a82984e0 100644
--- a/mingw-w64-crt/crt/crtdll_compat.c
+++ b/mingw-w64-crt/crt/crtdll_compat.c
Runtime library msvcrt10.dll like crtdll.dll does not provide support for
64-bit printf/scanf modifiers. So do not define them for msvcrt10.dll too.
---
mingw-w64-headers/crt/inttypes.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mingw-w64-headers/crt/inttypes.h
Import libraries for all these msvcrt versions are already as part of build
process.
---
mingw-w64-headers/configure.ac | 15 +++
1 file changed, 15 insertions(+)
diff --git a/mingw-w64-headers/configure.ac b/mingw-w64-headers/configure.ac
index 1307538ef480..d82280cd7515 100644
---
On Tuesday 08 February 2022 11:22:12 Martin Storsjö wrote:
> On Tue, 8 Feb 2022, LIU Hao wrote:
>
> > 在 2/8/22 16:33, Martin Storsjö 写道:
> > > On Sun, 6 Feb 2022, Pali Rohár wrote:
> > >
> > > > Mark _vscprintf() and _scprintf() functions with attribute
crtdll.mri is used only for building 32-bit version of libcrtdll.a library.
---
mingw-w64-crt/Makefile.am | 2 +-
mingw-w64-crt/{lib-common => lib32}/crtdll.mri | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename mingw-w64-crt/{lib-common => lib32}/crtdll.mri (100%)
Currently v*scanf functions are broken and crash when are called with more
than 30 arguments in va_list. This is because va_list v*scanf functions are
redirected to variadic *scanf functions and this redirect implemented in
scanf.S file has fixed limit for 30 arguments.
Number of arguments for
MinGW-w64 has same startup files for crtdll.dll and msvcrt.dll and defining
-D__CRTDLL__ or -D__MSVCRT__ has no effect on built *crt*.o files, they are
same. So build startup files only once and create other as copy from the
first one. Also remove -D__CRTDLL__ and -D__MSVCRT__ as they are not used
Import library libcrtdll.a (for crtdll.dll runtime library) compiled during
mingw-w64 build process is currently broken and cannot be used for linking
executable applications.
Trying to do it results in following linker errors:
/usr/bin/i686-w64-mingw32-ld: .../i686-w64-mingw32/lib/crt2.o: in
Mark _vscprintf() and _scprintf() functions with attribute pure as their
return value depends only on passed arguments.
In function __ms_vsnprintf() check only for n==0 and move _vscprintf() call
at the end of function. This allows LTO to optimize out _vscprintf() call
from __ms_vsnprintf()
On Wednesday 26 January 2022 14:45:58 LIU Hao wrote:
> 在 1/26/22 04:05, Pali Rohár 写道:
> >
> > Yes, this is truth. However amd64 asm code already reads more pointers
> > from stack (when number of them is smaller then number of arguments
> > needed to pass via registe
On Tuesday 08 February 2022 11:25:43 Martin Storsjö wrote:
> On Sun, 6 Feb 2022, Pali Rohár wrote:
>
> > Currently v*scanf functions are broken and crash when are called with more
> > than 30 arguments in va_list. This is because va_list v*scanf functions are
> > redir
On Monday 24 January 2022 13:41:27 Martin Storsjö wrote:
> On Sun, 16 Jan 2022, Pali Rohár wrote:
>
> > Currently v*scanf functions are broken and crash when are called with more
> > than 30 arguments in va_list. This is because va_list v*scanf functions are
> > redir
On Wednesday 26 January 2022 00:23:49 LIU Hao wrote:
> 在 2022-01-16 22:44, Pali Rohár 写道:
> > diff --git a/mingw-w64-crt/stdio/scanf2-argcount-template.c
> > b/mingw-w64-crt/stdio/scanf2-argcount-template.c
> > new file mode 100644
> > index ..c07e11797c39
On Friday 14 January 2022 13:45:38 Martin Storsjö wrote:
> On Fri, 14 Jan 2022, Pali Rohár wrote:
>
> > On Thursday 13 January 2022 23:22:10 Martin Storsjö wrote:
> > > On Wed, 12 Jan 2022, Pali Rohár wrote:
> > >
> > > > Original MSVC 6.0 msvc
On Saturday 12 March 2022 19:14:49 Biswapriyo Nath wrote:
> Just curious. If you have compiled a kernel driver with mingw-w64,
> would you like to provide the project link? I am eager to learn it.
Yes, I successfully compiled NT kernel driver with mingw-w64.
But due to lot of bugs in GCC and GNU
On Tuesday 18 October 2022 12:01:34 LIU Hao wrote:
> 在 2022/10/13 00:50, Pali Rohár 写道:
> > Hello! More mingw-w64 header files contain '#ifdef _MSVCRT_' code.
> > But _MSVCRT_ is not defined neither by gcc nor mingw-w64 runtime.
> > So it is a dead code? Or is there any pur
Hello!
I tried to develop simple NT kernel driver and build it via GNU GCC, LD
and mingw-w64 ecosystem but due to issues with compiler and linker, it
is not possible to generate final .sys binary without adding workarounds
or postprocessing resulted PE .sys binary.
I'm sending this email to all
On Monday 19 September 2022 15:33:45 Martin Storsjö wrote:
> On Sat, 17 Sep 2022, Pali Rohár wrote:
>
> > ---
> > mingw-w64-crt/Makefile.am| 3 +++
> > mingw-w64-crt/stdio/ucrt__scprintf.c | 21 +
> > mingw-w64-c
#if condition does not contain _CRTBLD check
---
mingw-w64-headers/crt/float.h| 2 +-
mingw-w64-headers/crt/io.h | 2 +-
mingw-w64-headers/crt/memory.h | 2 +-
mingw-w64-headers/crt/sec_api/conio_s.h | 2 +-
mingw-w64-headers/crt/sec_api/stdio_s.h | 2 +-
stdio/_vscprintf.c: In function ‘emu_vscprintf’:
stdio/_vscprintf.c:47:8: warning: ‘ret’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
if (ret < 0) {
^
---
mingw-w64-crt/stdio/_vscprintf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
---
mingw-w64-headers/crt/stdio.h | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index 76fffa177b10..1cebce723527 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@
---
mingw-w64-headers/crt/stdio.h | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index 1cebce723527..45b21d2997fb 100644
--- a/mingw-w64-headers/crt/stdio.h
+++
---
mingw-w64-crt/Makefile.am| 3 +++
mingw-w64-crt/stdio/ucrt__scprintf.c | 21 +
mingw-w64-crt/stdio/ucrt__snprintf.c | 21 +
mingw-w64-crt/stdio/ucrt__snscanf.c | 21 +
4 files changed, 66 insertions(+)
create mode
On Monday 19 September 2022 16:50:33 Martin Storsjö wrote:
> On Mon, 19 Sep 2022, Pali Rohár wrote:
>
> > On Monday 19 September 2022 15:33:45 Martin Storsjö wrote:
> > > On Sat, 17 Sep 2022, Pali Rohár wrote:
> > >
> > > > ---
> > > > mingw
Hello! More mingw-w64 header files contain '#ifdef _MSVCRT_' code.
But _MSVCRT_ is not defined neither by gcc nor mingw-w64 runtime.
So it is a dead code? Or is there any purpose for having those ifdefs?
Note that gcc defines macro __MSVCRT__ with double underscores.
On Monday 10 October 2022 14:25:07 Martin Storsjö wrote:
> Historically, the _CRTIMP macro comes from how it is used in upstream
> msvcrt; you can link the CRT either statically or dynamically. If intending
> to link statically, _CRTIMP expands to nothing, while if intending to link
> dyanmically,
_HUGE global variable is available and exported from crtdll and msvcrt
libraries. So declare it explicitly via _CRTIMP as global variable and not
via __MINGW_IMP_SYMBOL pointer.
---
I'm really not sure what was the reason to define _HUGE via macro
__MINGW_IMP_SYMBOL poinster. So maybe there is a
On Saturday 08 October 2022 23:57:06 LIU Hao wrote:
> 在 2022-10-08 21:15, Pali Rohár 写道:
> >
> > Is not _CRTIMP automatically marking variable with dllimport and
> > instruct compiler to convert variable name to __imp_name* pointer?
>
> Not always, at least. When bui
On Saturday 08 October 2022 20:07:56 LIU Hao wrote:
> 在 2022/10/8 19:10, Pali Rohár 写道:
> > _HUGE global variable is available and exported from crtdll and msvcrt
> > libraries. So declare it explicitly via _CRTIMP as global variable and not
> > via __MINGW_IMP_SYMBOL po
On Saturday 24 December 2022 11:48:51 LIU Hao wrote:
> 在 2022-12-24 06:14, Pali Rohár 写道:
> > I just quickly tested it only in wine. Without LTO it prints "ł$"
> > (really strange, looks like some memory problem, maybe in wine?).
> >
>
>
On Sunday 25 December 2022 17:21:50 LIU Hao wrote:
> 在 2022-12-25 02:19, Pali Rohár 写道:
> > This patch fixes it! And also in LTO mode it prints "test thread atexit".
> >
>
> Mostly good. Should `__xl_d` be given an attribute as well?
It is not referenced anywher
On Wednesday 21 December 2022 14:54:13 Martin Storsjö wrote:
> On Sat, 17 Dec 2022, LIU Hao wrote:
>
> > 在 2022-12-17 20:01, Pali Rohár 写道:
> > > It would be nice if somebody who understand these patterns write some
> > > comment what is the real purpose of the fi
Hello! I would like to remind this thread for gcc/binutils developers.
Most of these issues are still present and cause problems for compiling
native PE binary. If you have questions or you need any other information
please let me know.
On Sunday 30 October 2022 02:06:11 Pali Rohár wrote:
> He
On Friday 23 December 2022 22:25:57 LIU Hao wrote:
> 在 2022-12-21 21:00, Martin Storsjö 写道:
> >
> > I believe this patch should be harmless; for regular object file based
> > linking, __attribute__((used)) shouldn't have any effect across object
> > file boundaries (it only affects what's emitted
On Friday 23 December 2022 22:20:25 LIU Hao wrote:
> 在 2022-12-04 21:49, Pali Rohár 写道:
> > Format attributes is interesting issue. Because there are already following
> > printf implementations:
> >
> > 1) C89 (without %lld) (crtdll.dll, msvcrt10.dll)
> > 2) C
Hello! I did another test on master branch of mingw-w64 with very simple
snprintf test.c program which does not include any header file:
typedef long unsigned int size_t;
int __cdecl snprintf(char *buffer, size_t n, const char *format, ...);
int main(int argc, char *argv[]) {
char
On Saturday 19 November 2022 15:42:45 Pali Rohár wrote:
> On Saturday 19 November 2022 11:53:28 Pali Rohár wrote:
> > On Saturday 19 November 2022 17:12:12 LIU Hao wrote:
> > > 在 2022-11-18 23:40, Pali Rohár 写道:
> > > > GNU LD provides __ImageBase symbol since
On Thursday 29 December 2022 13:09:18 Martin Storsjö wrote:
> > > The question is now how to handle this issue? Based on this testing, I
> > > do not see what can be done. weak should not be used, LTO also (and does
> > > not work with old gcc), moving symbol to header file does not sounds
> > >
On Saturday 24 December 2022 03:17:57 LIU Hao wrote:
> 在 2022-12-24 01:43, Pali Rohár 写道:
> > Ou right. They would also require __attribute__((used)) for LTO builds.
> > I just tested simple single process/thread console applications and they
> > worked.
> >
&g
On Saturday 24 December 2022 01:00:59 LIU Hao wrote:
> 在 2022-12-24 00:18, Pali Rohár 写道:
> > What is the reason? Maybe it was gcc/ld bug which this patch workarounds?
> >
>
> Generally speaking, all variables that are required to be placed in special
>
On Tuesday 27 December 2022 14:38:00 LIU Hao wrote:
> Variables that are required to be placed in explicit sections probably
> have special meanings, and shall not be eliminated by LTO. Preserving
> all of them might look an overkill, but should be safest.
>
> Signed-off-by: LIU Hao
> ---
>
Include file msvcrt-common.def.in contains moldname aliases and 4 export
symbols: longjmp, _daylight, _timezone, _tzname.
Move these 4 export symbols from msvcrt-common.def.in file into all files
which include msvcrt-common.def.in. So all msvcrt def files would contain
all exported symbols
It is unused since commit 99c69c2fe5d8 ("lib64/msvcrt.def: include moldname
contents") from April 2013.
---
mingw-w64-crt/lib64/moldname-msvcrt.def | 149
1 file changed, 149 deletions(-)
delete mode 100644 mingw-w64-crt/lib64/moldname-msvcrt.def
diff --git
moldname content is already included in all other msvcrt def files. This
allows applications to use moldname aliases defined in msvcrt-common.def.in
also when linking with other crt dll libraries.
---
mingw-w64-crt/Makefile.am | 3 ++-
mingw-w64-crt/lib32/{crtdll.def
File msvcrt-common.def.in is included only in x86 32 and 64 bit msvcrt def
files and common msvcrt.def.in file. After moving longjmp, _daylight,
_timezone and _tzname out of the msvcrt-common.def.in file, this file would
contain only symbol aliases and not export symbols anymore. This makes
On Thursday 20 October 2022 21:44:36 Pali Rohár wrote:
> On Tuesday 18 October 2022 12:01:34 LIU Hao wrote:
> > 在 2022/10/13 00:50, Pali Rohár 写道:
> > > Hello! More mingw-w64 header files contain '#ifdef _MSVCRT_' code.
> > > But _MSVCRT_ is not defined neither b
These symbols are global read/write variables and therefore must be
declared with DATA keyword, even when they are just aliases to other
symbols. Otherwise GNU dlltool generates for each of those symbols also
function thunk code.
---
mingw-w64-crt/def-include/msvcrt-common.def.in | 6 +++---
1
On Saturday 17 December 2022 23:01:10 LIU Hao wrote:
> 在 2022-12-17 22:22, Pali Rohár 写道:
> > Currently when linking target application with LTO builds of mingw-w64
> > libraries, it is needed to manually specify entry point of mingw-w64 crt
> > startup function v
Currently when linking target application with LTO builds of mingw-w64
libraries, it is needed to manually specify entry point of mingw-w64 crt
startup function via linker flag -Wl,-e,_mainCRTStartup (for console
executables) or -Wl,-e,_WinMainCRTStartup (for GUI executables) or
mingw-w64-headers/crt/_mingw.h: In function ‘__fastfail’:
mingw-w64-headers/crt/_mingw.h:615:1: warning: ‘noreturn’ function does
return
}
^
---
mingw-w64-headers/crt/_mingw.h.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/mingw-w64-headers/crt/_mingw.h.in
Function lldiv() is available since msvcr100.dll and function imaxdiv()
since msvcr120.dll. So for msvcr100.dll and msvcr110.dll define imaxdiv()
as alias to lldiv(). And for older msvcrt versions include mingw-w64
implementation from imaxdiv.c. Do not pack mingw-w64 implementation of
imaxdiv()
1 - 100 of 286 matches
Mail list logo
