Re: [Mingw-w64-public] [PATCH] crt: msvcr70.def.in: Add missing @SIZE suffixes and __CxxCallUnwindVecDtor
在 2024-04-16 05:57, Pali Rohár 写道: There is one another thing suspicious here. Function takes two float arguments, but one argument is passed via floating-point register and another via stack. Yes it looks like the case. From what I found on internet, it looks like that stdcall calling convention never use floating-point registers for passing arguments. So this function cannot be real stdcall. For x86, floating-point arguments are always passed on stack except with `__vectorcall`. This function looks like kinda modified `__fastcall` ones; it does not look like a public calling convention. I think it is better to be compatible with MSVC object level behavior than inventing new/custom object level behavior. Meaning to export it from def file without @SIZE. But I think it is not possible to write declaration for this function into header file. Because __attribute__((stdcall)) annotation cause that all arguments are passed via stack. I looked at gcc documentation https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html and there is nothing which can tell to gcc compiler that first floating point argument is passed in x87 register instead of the stack. Maybe clang supports something? If these are functions necessary by the Microsoft compiler (random posts on Google suggest they have been there to work around the Intel division bug) and not meant to be called by users, maybe we just shouldn't provide them. -- 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] crt: msvcr71.def.in: Add missing @SIZE suffixes
Please drop this change. It is also false positive stdcall decoration by gendef for functions which do not return. On Sunday 14 April 2024 22:52:59 Pali Rohár wrote: > Symbols _assert@4 and abort@4 in all versions of msvcr71.dll have @SIZE > suffixes. Without @SIZE suffixes they are only in debug msvcr71d.dll > library versions and Itanium msvcr70.dll versions. But all those libraries > have different name, not compatible with msvcr71.def.in file. So update > msvcr71.def.in to match Visual Studio .NET 2003 version, same set of > symbols is also in Service Pack 1 version. > --- > mingw-w64-crt/lib32/msvcr71.def.in | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mingw-w64-crt/lib32/msvcr71.def.in > b/mingw-w64-crt/lib32/msvcr71.def.in > index 66c87d1dc654..52c0fd6001aa 100644 > --- a/mingw-w64-crt/lib32/msvcr71.def.in > +++ b/mingw-w64-crt/lib32/msvcr71.def.in > @@ -253,7 +253,7 @@ _aligned_offset_malloc > _aligned_offset_realloc > _aligned_realloc > _amsg_exit > -_assert > +_assert@4 > _atodbl > _atoi64 > atoll == _atoi64 > @@ -710,7 +710,7 @@ _wutime64 > _y0 > _y1 > _yn > -abort > +abort@4 > abs > acos > asctime > -- > 2.20.1 > ___ 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] crt: msvcr70.def.in: Add missing @SIZE suffixes and __CxxCallUnwindVecDtor
On Monday 15 April 2024 23:40:34 Martin Storsjö wrote: > On Mon, 15 Apr 2024, Pali Rohár wrote: > > > > These functions are exported on the DLL interface as plain "name". When we > > > call them, via a declaration marked as stdcall in C, it does produce a > > > call > > > to the symbol "_name@size" instead of the regular "_name". This > > > information > > > is not visible on the external DLL interface at all. > > > > I was totally confused how it works. And now I figured out that import > > libraries in mingw-w64 repository are generated with -k (--kill-at) > > parameter for dlltool, which removes that @SIZE suffix from the symbol > > name which is put into import table of the executable. > > > > In past I generated import libraries from def files without -k argument > > which seems that use 1:1 mapping between symbol in def file and in > > import table. > > Indeed, it's possible to use dlltool that way, but then it'd be pretty messy > to generate import libraries that work for these kinds of DLLs. > > > > Gendef tries to look at the actual contents of the function, and uses > > > heuristics to guess whether the function uses stdcall or cdecl calling > > > convention. It's not foolproof though, as Liu Hao pointed out. objdump > > > only > > > looks at the DLL export table, and I presume readpe does that as well. > > > > So... if I understand it correctly then gendef tries to generate def > > file which has to be processed by -k (--kill-at) argument of dlltool. > > Yes, exactly. > > // Martin Thanks you. I hope that now I understood it. And sorry for it. ___ 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] crt: msvcr70.def.in: Add missing @SIZE suffixes and __CxxCallUnwindVecDtor
On Monday 15 April 2024 23:50:09 Martin Storsjö wrote:
> On Mon, 15 Apr 2024, Pali Rohár wrote:
>
> > On Monday 15 April 2024 10:49:43 Martin Storsjö wrote:
> > > Or just compiling a test C file with the corresponding
> > > MSVC version and looking at the generated object file to see what symbol
> > > reference it generated.
> >
> > So... now I did an experiment with VC4.2 CL.EXE (first version which
> > generate code for msvcrt.dll) and VC4.1 CL.EXE (last version which
> > generate code for msvcr40.dll).
> >
> > Source code:
> >
> >float __cdecl fdiv(float a, float b) { return a / b; }
> >
> > Compiled with:
> >
> >CL.EXE /c /QIfdiv /O2
> >
> > Both 4.1 and 4.2 versions of CL.EXE generated same obj file which under
> > objdump -dr looks like:
> >
> >Disassembly of section .text:
> >
> > <_fdiv>:
> > 0: d9 44 24 04 flds 0x4(%esp)
> > 4: 83 3d 00 00 00 00 00cmpl $0x0,0x0
> >6: dir32__adjust_fdiv
> > b: 75 06 jne13 <_fdiv+0x13>
> > d: d8 74 24 08 fdivs 0x8(%esp)
> > 11: eb 09 jmp1c <_fdiv+0x1c>
> > 13: ff 74 24 08 pushl 0x8(%esp)
> > 17: e8 00 00 00 00 call 1c <_fdiv+0x1c>
> >18: DISP32 __adj_fdiv_m32
> > 1c: c3 ret
> >
> >
> > So what does it say about __adjust_fdiv and __adj_fdiv_m32 symbols?
> > If my understanding is correct then __adjust_fdiv is global variable
>
> Yes, I would agree about that
>
> > and __adj_fdiv_m32 is a function which takes first float argument in x87
> > ST(0) register, second float argument on the stack and function itself
> > pops the stack (the second float argument).
>
> This seems to be true as well, yes. I.e. the function uses stdcall calling
> convention.
Ok, thank you for confirmation.
> > Now I checked all versions of msvcrt40.dll libraries which I found
> > (including OS system versions) and all have symbol name "_adj_fdiv_m32"
> > in their import tables.
>
> Ok, so that would correspond to the same pattern as many of these others,
> that the DLL exports an undecorated name.
>
> > So does it mean that "_adj_fdiv_m32" (and possibly also all other _adj_*
> > symbols) use stdcall calling convention, and should be defined with
> > @SIZE suffix in the .def file?
>
> Hmm, maybe.
>
> If _adj_fdiv_m32 would be a regular C function, it should be declared
> stdcall, in order to get the stack adjustment behaviour you described. But
> if you'd have a stdcall function, then the object file level references to
> it would be "__adj_fdiv_m32@4" as well - but the MSVC produced object file
> doesn't have that.
>
> So it seems to me that this isn't a regular C level function in any case,
> but the compiler generates calls, with the stdcall calling convention, but
> without stdcall name mangling on the symbol. And there's no declaration of
> the function in any header, as it's not meant to be called as such, only
> called by compiler generated code.
There is one another thing suspicious here. Function takes two float
arguments, but one argument is passed via floating-point register and
another via stack.
From what I found on internet, it looks like that stdcall calling
convention never use floating-point registers for passing arguments.
So this function cannot be real stdcall.
> So exactly what we place in our def file is pretty much up to us in that
> case. If we would add a declaration of the function in our headers, we'd
> need to declare it stdcall - then the object file level name would include
> the @size, and we'd need to place this in the def file.
>
> But if we'd want to match the MSVC object level behaviour for this function,
> we could also keep the name in the def file undecorated. If we'd have a
> declaration in a header, we could add an asm("") name to it, to signify that
> even if the function is stdcall, the symbol name is different.
>
> But as the function isn't meant to be called from user C code, we might not
> need to do that at all. So we could just leave it without the @size part,
> matching MSVC, and if we'd make GCC or Clang generate calls to it, we'd make
> them generate calls to "__adj_fdiv_m32" without the @size, just like MSVC
> did.
>
> So all in all, this looks like a special case function, and there's no clear
> answer what we should place in the def file. I would maybe prefer keeping it
> without @size as that's how MSVC references it (but I don't have a strong
> opinion on it), and then add a comment that it's an odd stdcall function
> without the typical stdcall suffix on the symbol name.
>
> // Martin
I think it is better to be compatible with MSVC object level behavior
than inventing new/custom object level behavior. Meaning to export it
from def file without @SIZE.
But I think it is not possible to write declaration for this function
into header file.
Re: [Mingw-w64-public] [PATCH 1/2] crt/xaudio2_9: Fix export names of `X3DAudioCalculate` and `X3DAudioInitialize`
On Mon, 15 Apr 2024, LIU Hao wrote: -- Thanks, I think this patch (1/2) is fine. // 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 2/2] crt: Fix some symbols with duplicate stdcall suffixes
On Tue, 16 Apr 2024, LIU Hao wrote: 1. There is currently no 'x3daudio.h' in mingw-w64. Wine and Windows SDK headers have `X3DAudioInitialize()` and `X3DAudioCalculate()` as `__cdecl`, but they are really `__stdcall` in X3DAUDIO1_2.DLL. 2. The macros `ADD_UNDERSCORE()` and `ADD_DOUBLE_UNDERSCORE()` are moved from 'msvcrt-common.def.in' to 'func.def.in' so they can be reused. Previously they were only used by 'msvcr*.def.in'. Hmm, I would prefer if you'd add a new macro for this purpose, instead of reusing the old one. The old existing one is used to add aliases for functions, usually like this: --- _somefunc ADD_UNDERSCORE(somefunc) --- But here, you're adding an alias as a way to specify the literal DLL import name, as a way to undo the effect of dlltool's "-k" option for one single symbol. So I see it semantically as a different thing, so a new macro, e.g. "LITERAL_STDCALL(somefunc@4)" instead. Or maybe KEEP_STDCALL() or something like that? (The reason why I want to make the distinction, is both because I feel that it's semantically a different thing, but also because llvm-dlltool doesn't handle this exact case right now, it only works with the aliases in the former style. But I think it should be possible to improve llvm-dlltool to make this case work as well.) // 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] crt: msvcr70.def.in: Add missing @SIZE suffixes and __CxxCallUnwindVecDtor
On Mon, 15 Apr 2024, Pali Rohár wrote:
On Monday 15 April 2024 10:49:43 Martin Storsjö wrote:
Or just compiling a test C file with the corresponding
MSVC version and looking at the generated object file to see what symbol
reference it generated.
So... now I did an experiment with VC4.2 CL.EXE (first version which
generate code for msvcrt.dll) and VC4.1 CL.EXE (last version which
generate code for msvcr40.dll).
Source code:
float __cdecl fdiv(float a, float b) { return a / b; }
Compiled with:
CL.EXE /c /QIfdiv /O2
Both 4.1 and 4.2 versions of CL.EXE generated same obj file which under
objdump -dr looks like:
Disassembly of section .text:
<_fdiv>:
0: d9 44 24 04 flds 0x4(%esp)
4: 83 3d 00 00 00 00 00cmpl $0x0,0x0
6: dir32__adjust_fdiv
b: 75 06 jne13 <_fdiv+0x13>
d: d8 74 24 08 fdivs 0x8(%esp)
11: eb 09 jmp1c <_fdiv+0x1c>
13: ff 74 24 08 pushl 0x8(%esp)
17: e8 00 00 00 00 call 1c <_fdiv+0x1c>
18: DISP32 __adj_fdiv_m32
1c: c3 ret
So what does it say about __adjust_fdiv and __adj_fdiv_m32 symbols?
If my understanding is correct then __adjust_fdiv is global variable
Yes, I would agree about that
and __adj_fdiv_m32 is a function which takes first float argument in x87
ST(0) register, second float argument on the stack and function itself
pops the stack (the second float argument).
This seems to be true as well, yes. I.e. the function uses stdcall calling
convention.
Now I checked all versions of msvcrt40.dll libraries which I found
(including OS system versions) and all have symbol name "_adj_fdiv_m32"
in their import tables.
Ok, so that would correspond to the same pattern as many of these others,
that the DLL exports an undecorated name.
So does it mean that "_adj_fdiv_m32" (and possibly also all other _adj_*
symbols) use stdcall calling convention, and should be defined with
@SIZE suffix in the .def file?
Hmm, maybe.
If _adj_fdiv_m32 would be a regular C function, it should be declared
stdcall, in order to get the stack adjustment behaviour you described. But
if you'd have a stdcall function, then the object file level references to
it would be "__adj_fdiv_m32@4" as well - but the MSVC produced object file
doesn't have that.
So it seems to me that this isn't a regular C level function in any case,
but the compiler generates calls, with the stdcall calling convention, but
without stdcall name mangling on the symbol. And there's no declaration of
the function in any header, as it's not meant to be called as such, only
called by compiler generated code.
So exactly what we place in our def file is pretty much up to us in that
case. If we would add a declaration of the function in our headers, we'd
need to declare it stdcall - then the object file level name would include
the @size, and we'd need to place this in the def file.
But if we'd want to match the MSVC object level behaviour for this
function, we could also keep the name in the def file undecorated. If we'd
have a declaration in a header, we could add an asm("") name to it, to
signify that even if the function is stdcall, the symbol name is
different.
But as the function isn't meant to be called from user C code, we might
not need to do that at all. So we could just leave it without the @size
part, matching MSVC, and if we'd make GCC or Clang generate calls to it,
we'd make them generate calls to "__adj_fdiv_m32" without the @size, just
like MSVC did.
So all in all, this looks like a special case function, and there's no
clear answer what we should place in the def file. I would maybe prefer
keeping it without @size as that's how MSVC references it (but I don't
have a strong opinion on it), and then add a comment that it's an odd
stdcall function without the typical stdcall suffix on the symbol name.
// 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] crt: msvcr70.def.in: Add missing @SIZE suffixes and __CxxCallUnwindVecDtor
On Mon, 15 Apr 2024, Pali Rohár wrote: These functions are exported on the DLL interface as plain "name". When we call them, via a declaration marked as stdcall in C, it does produce a call to the symbol "_name@size" instead of the regular "_name". This information is not visible on the external DLL interface at all. I was totally confused how it works. And now I figured out that import libraries in mingw-w64 repository are generated with -k (--kill-at) parameter for dlltool, which removes that @SIZE suffix from the symbol name which is put into import table of the executable. In past I generated import libraries from def files without -k argument which seems that use 1:1 mapping between symbol in def file and in import table. Indeed, it's possible to use dlltool that way, but then it'd be pretty messy to generate import libraries that work for these kinds of DLLs. Gendef tries to look at the actual contents of the function, and uses heuristics to guess whether the function uses stdcall or cdecl calling convention. It's not foolproof though, as Liu Hao pointed out. objdump only looks at the DLL export table, and I presume readpe does that as well. So... if I understand it correctly then gendef tries to generate def file which has to be processed by -k (--kill-at) argument of dlltool. Yes, exactly. // 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] crt: msvcr70.def.in: Add missing @SIZE suffixes and __CxxCallUnwindVecDtor
On Monday 15 April 2024 10:49:43 Martin Storsjö wrote:
> Or just compiling a test C file with the corresponding
> MSVC version and looking at the generated object file to see what symbol
> reference it generated.
So... now I did an experiment with VC4.2 CL.EXE (first version which
generate code for msvcrt.dll) and VC4.1 CL.EXE (last version which
generate code for msvcr40.dll).
Source code:
float __cdecl fdiv(float a, float b) { return a / b; }
Compiled with:
CL.EXE /c /QIfdiv /O2
Both 4.1 and 4.2 versions of CL.EXE generated same obj file which under
objdump -dr looks like:
Disassembly of section .text:
<_fdiv>:
0: d9 44 24 04 flds 0x4(%esp)
4: 83 3d 00 00 00 00 00cmpl $0x0,0x0
6: dir32__adjust_fdiv
b: 75 06 jne13 <_fdiv+0x13>
d: d8 74 24 08 fdivs 0x8(%esp)
11: eb 09 jmp1c <_fdiv+0x1c>
13: ff 74 24 08 pushl 0x8(%esp)
17: e8 00 00 00 00 call 1c <_fdiv+0x1c>
18: DISP32 __adj_fdiv_m32
1c: c3 ret
So what does it say about __adjust_fdiv and __adj_fdiv_m32 symbols?
If my understanding is correct then __adjust_fdiv is global variable
and __adj_fdiv_m32 is a function which takes first float argument in x87
ST(0) register, second float argument on the stack and function itself
pops the stack (the second float argument).
Now I checked all versions of msvcrt40.dll libraries which I found
(including OS system versions) and all have symbol name "_adj_fdiv_m32"
in their import tables.
So does it mean that "_adj_fdiv_m32" (and possibly also all other _adj_*
symbols) use stdcall calling convention, and should be defined with
@SIZE suffix in the .def file?
___
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] crt: msvcr70.def.in: Add missing @SIZE suffixes and __CxxCallUnwindVecDtor
On Monday 15 April 2024 10:49:43 Martin Storsjö wrote: > On Mon, 15 Apr 2024, Pali Rohár wrote: > > > On Monday 15 April 2024 09:19:09 LIU Hao wrote: > > > 在 2024-04-15 04:52, Pali Rohár 写道: > > > > Symbols _assert@4 and abort@4 in all versions of msvcr70.dll have @SIZE > > > > suffixes. Without @SIZE suffixes they are only in debug msvcr70d.dll > > > > library versions and Itanium msvcr70.dll versions. > > > > > > > > > > I think these are kinda false positives. The stdcall suffixes are deduced > > > by > > > gendef from machine code, and are not part of the actual export name. > > > These > > > functions do not return and might have no meaningful RET instructions. > > > > Ou. Now I checked export names via objdump and rechecked also via > > readpe. And both tools say that they are without @SIZE suffix. > > Checking with objdump won't ever show a @size suffix, and I presume readpe > does the same. Both show name stored in export table. > These functions are exported on the DLL interface as plain "name". When we > call them, via a declaration marked as stdcall in C, it does produce a call > to the symbol "_name@size" instead of the regular "_name". This information > is not visible on the external DLL interface at all. I was totally confused how it works. And now I figured out that import libraries in mingw-w64 repository are generated with -k (--kill-at) parameter for dlltool, which removes that @SIZE suffix from the symbol name which is put into import table of the executable. In past I generated import libraries from def files without -k argument which seems that use 1:1 mapping between symbol in def file and in import table. > Gendef tries to look at the actual contents of the function, and uses > heuristics to guess whether the function uses stdcall or cdecl calling > convention. It's not foolproof though, as Liu Hao pointed out. objdump only > looks at the DLL export table, and I presume readpe does that as well. So... if I understand it correctly then gendef tries to generate def file which has to be processed by -k (--kill-at) argument of dlltool. > So other than that, we can only look at the declarations in C headers. In > this case, looking at our own headers might not help if it's not up to date > for exactly this msvcrt DLL though, but looking at the corresponding MSVC > header might help. (Or just compiling a test C file with the corresponding > MSVC version and looking at the generated object file to see what symbol > reference it generated.) This doesn't help for undocumented/undeclared > private symbols though. > > // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 2/2] crt: Fix some symbols with duplicate stdcall suffixes
1. There is currently no 'x3daudio.h' in mingw-w64. Wine and Windows SDK
headers have
`X3DAudioInitialize()` and `X3DAudioCalculate()` as `__cdecl`, but they are
really
`__stdcall` in X3DAUDIO1_2.DLL.
2. The macros `ADD_UNDERSCORE()` and `ADD_DOUBLE_UNDERSCORE()` are moved from
'msvcrt-common.def.in' to 'func.def.in' so they can be reused. Previously
they
were only used by 'msvcr*.def.in'.
3. 'lib32/usbd.def' was regenerated from USBD.SYS from Windows XP 32-bit.
--
Best regards,
LIU Hao
From 357c980c8a7b472a8e115b7af942531be915242b Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Mon, 15 Apr 2024 23:08:08 +0800
Subject: [PATCH 2/2] crt: Fix some symbols with duplicate stdcall suffixes
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. We have the macro `ADD_UNDERSCORE()` for them.
This fixes errors like
#include
#include
/* 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
---
mingw-w64-crt/def-include/func.def.in | 3 +++
mingw-w64-crt/def-include/msvcrt-common.def.in | 3 ---
mingw-w64-crt/lib32/mstask.def | 13 -
mingw-w64-crt/lib32/msvcr100.def.in| 4 ++--
mingw-w64-crt/lib32/msvcr90.def.in | 4 ++--
mingw-w64-crt/lib32/msvcr90d.def.in| 4 ++--
mingw-w64-crt/lib32/msvcrt20.def.in| 2 +-
mingw-w64-crt/lib32/t2embed.def| 11 ---
mingw-w64-crt/lib32/usbd.def | 12 +++-
mingw-w64-crt/lib32/x3daudio1_2.def| 11 ---
mingw-w64-crt/lib32/x3daudio1_2.def.in | 6 ++
11 files changed, 19 insertions(+), 54 deletions(-)
delete mode 100644 mingw-w64-crt/lib32/x3daudio1_2.def
create mode 100644 mingw-w64-crt/lib32/x3daudio1_2.def.in
diff --git a/mingw-w64-crt/def-include/func.def.in
b/mingw-w64-crt/def-include/func.def.in
index 58cc36d86..c67b6efe1 100644
--- a/mingw-w64-crt/def-include/func.def.in
+++ b/mingw-w64-crt/def-include/func.def.in
@@ -55,3 +55,6 @@
#ifndef F_NON_I386
#define F_NON_I386(x)
#endif
+
+#define ADD_UNDERSCORE(symbol) symbol == _ ## symbol
+#define ADD_DOUBLE_UNDERSCORE(symbol) symbol == __ ## symbol
diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in
b/mingw-w64-crt/def-include/msvcrt-common.def.in
index 9728b5ab8..80ce5e9fe 100644
--- a/mingw-w64-crt/def-include/msvcrt-common.def.in
+++ b/mingw-w64-crt/def-include/msvcrt-common.def.in
@@ -1,8 +1,5 @@
#include "func.def.in"
-#define ADD_UNDERSCORE(symbol) symbol == _ ## symbol
-#define ADD_DOUBLE_UNDERSCORE(symbol) symbol == __ ## symbol
-
ADD_DOUBLE_UNDERSCORE(iscsymf)
ADD_DOUBLE_UNDERSCORE(iscsym)
ADD_DOUBLE_UNDERSCORE(isascii)
diff --git a/mingw-w64-crt/lib32/mstask.def b/mingw-w64-crt/lib32/mstask.def
index 2cc5298e7..ba8f873a0 100644
--- a/mingw-w64-crt/lib32/mstask.def
+++ b/mingw-w64-crt/lib32/mstask.def
@@ -18,16 +18,3 @@ SAGetNSAccountInformation@12
SASetAccountInformation@20
SASetNSAccountInformation@12
SetNetScheduleAccountInformation@12
-_ConvertAtJobsToTasks@0@0
-_DllCanUnloadNow@0@0
-_DllGetClassObject@12@12
-_GetNetScheduleAccountInformation@12@12
-_NetrJobAdd@12@12
-_NetrJobDel@12@12
-_NetrJobEnum@20@20
-_NetrJobGetInfo@12@12
-_SAGetAccountInformation@16@16
-_SAGetNSAccountInformation@12@12
-_SASetAccountInformation@20@20
-_SASetNSAccountInformation@12@12
-_SetNetScheduleAccountInformation@12@12
diff --git a/mingw-w64-crt/lib32/msvcr100.def.in
b/mingw-w64-crt/lib32/msvcr100.def.in
index e2e0e18c7..b802b288c 100644
--- a/mingw-w64-crt/lib32/msvcr100.def.in
+++ b/mingw-w64-crt/lib32/msvcr100.def.in
@@ -626,8 +626,8 @@ __daylight
__dllonexit
__doserrno
__dstbias
-___fls_getvalue@4@4
-___fls_setvalue@8@8
+ADD_UNDERSCORE(__fls_getvalue@4)
+ADD_UNDERSCORE(__fls_setvalue@8)
__fpecode
__free_locale
__get_current_locale
diff --git a/mingw-w64-crt/lib32/msvcr90.def.in
b/mingw-w64-crt/lib32/msvcr90.def.in
index 4424adfe5..1bc161a5f 100644
--- a/mingw-w64-crt/lib32/msvcr90.def.in
+++ b/mingw-w64-crt/lib32/msvcr90.def.in
@@ -230,8 +230,8 @@ __daylight
__dllonexit
__doserrno
__dstbias
-___fls_getvalue@4@4
-___fls_setvalue@8@8
+ADD_UNDERSCORE(__fls_getvalue@4)
+ADD_UNDERSCORE(__fls_setvalue@8)
__fpecode
__free_locale
__get_app_type
diff --git a/mingw-w64-crt/lib32/msvcr90d.def.in
b/mingw-w64-crt/lib32/msvcr90d.def.in
index 2835301f0..61c63b65b 100644
[Mingw-w64-public] [PATCH 1/2] crt/xaudio2_9: Fix export names of `X3DAudioCalculate` and `X3DAudioInitialize`
--
Best regards,
LIU Hao
From b8b2b024cde9fd66b2280cba7ed995771882b366 Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Mon, 15 Apr 2024 23:30:50 +0800
Subject: [PATCH 1/2] crt/xaudio2_9: Fix export names of `X3DAudioCalculate`
and `X3DAudioInitialize`
These are not `__stdcall` functions, but `__cdecl` ones.
N.B. it was `__stdcall` in X3DAUDIO1_2.
Signed-off-by: LIU Hao
---
mingw-w64-crt/lib32/xaudio2_9.def | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-crt/lib32/xaudio2_9.def
b/mingw-w64-crt/lib32/xaudio2_9.def
index b283fab53..610271dc5 100644
--- a/mingw-w64-crt/lib32/xaudio2_9.def
+++ b/mingw-w64-crt/lib32/xaudio2_9.def
@@ -9,8 +9,8 @@ XAudio2Create@12
CreateAudioReverb@4
CreateAudioVolumeMeter@4
CreateFX@0
-X3DAudioCalculate@0
-X3DAudioInitialize@0
+X3DAudioCalculate
+X3DAudioInitialize
CreateAudioReverbV2_8@4
XAudio2CreateV2_9@12
XAudio2CreateWithVersionInfo@16
--
2.44.0
From 357c980c8a7b472a8e115b7af942531be915242b Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Mon, 15 Apr 2024 23:08:08 +0800
Subject: [PATCH 2/2] crt: Fix some symbols with duplicate stdcall suffixes
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. We have the macro `ADD_UNDERSCORE()` for them.
This fixes errors like
#include
#include
/* 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
---
mingw-w64-crt/def-include/func.def.in | 3 +++
mingw-w64-crt/def-include/msvcrt-common.def.in | 3 ---
mingw-w64-crt/lib32/mstask.def | 13 -
mingw-w64-crt/lib32/msvcr100.def.in| 4 ++--
mingw-w64-crt/lib32/msvcr90.def.in | 4 ++--
mingw-w64-crt/lib32/msvcr90d.def.in| 4 ++--
mingw-w64-crt/lib32/msvcrt20.def.in| 2 +-
mingw-w64-crt/lib32/t2embed.def| 11 ---
mingw-w64-crt/lib32/usbd.def | 12 +++-
mingw-w64-crt/lib32/x3daudio1_2.def| 11 ---
mingw-w64-crt/lib32/x3daudio1_2.def.in | 6 ++
11 files changed, 19 insertions(+), 54 deletions(-)
delete mode 100644 mingw-w64-crt/lib32/x3daudio1_2.def
create mode 100644 mingw-w64-crt/lib32/x3daudio1_2.def.in
diff --git a/mingw-w64-crt/def-include/func.def.in
b/mingw-w64-crt/def-include/func.def.in
index 58cc36d86..c67b6efe1 100644
--- a/mingw-w64-crt/def-include/func.def.in
+++ b/mingw-w64-crt/def-include/func.def.in
@@ -55,3 +55,6 @@
#ifndef F_NON_I386
#define F_NON_I386(x)
#endif
+
+#define ADD_UNDERSCORE(symbol) symbol == _ ## symbol
+#define ADD_DOUBLE_UNDERSCORE(symbol) symbol == __ ## symbol
diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in
b/mingw-w64-crt/def-include/msvcrt-common.def.in
index 9728b5ab8..80ce5e9fe 100644
--- a/mingw-w64-crt/def-include/msvcrt-common.def.in
+++ b/mingw-w64-crt/def-include/msvcrt-common.def.in
@@ -1,8 +1,5 @@
#include "func.def.in"
-#define ADD_UNDERSCORE(symbol) symbol == _ ## symbol
-#define ADD_DOUBLE_UNDERSCORE(symbol) symbol == __ ## symbol
-
ADD_DOUBLE_UNDERSCORE(iscsymf)
ADD_DOUBLE_UNDERSCORE(iscsym)
ADD_DOUBLE_UNDERSCORE(isascii)
diff --git a/mingw-w64-crt/lib32/mstask.def b/mingw-w64-crt/lib32/mstask.def
index 2cc5298e7..ba8f873a0 100644
--- a/mingw-w64-crt/lib32/mstask.def
+++ b/mingw-w64-crt/lib32/mstask.def
@@ -18,16 +18,3 @@ SAGetNSAccountInformation@12
SASetAccountInformation@20
SASetNSAccountInformation@12
SetNetScheduleAccountInformation@12
-_ConvertAtJobsToTasks@0@0
-_DllCanUnloadNow@0@0
-_DllGetClassObject@12@12
-_GetNetScheduleAccountInformation@12@12
-_NetrJobAdd@12@12
-_NetrJobDel@12@12
-_NetrJobEnum@20@20
-_NetrJobGetInfo@12@12
-_SAGetAccountInformation@16@16
-_SAGetNSAccountInformation@12@12
-_SASetAccountInformation@20@20
-_SASetNSAccountInformation@12@12
-_SetNetScheduleAccountInformation@12@12
diff --git a/mingw-w64-crt/lib32/msvcr100.def.in
b/mingw-w64-crt/lib32/msvcr100.def.in
index e2e0e18c7..b802b288c 100644
--- a/mingw-w64-crt/lib32/msvcr100.def.in
+++ b/mingw-w64-crt/lib32/msvcr100.def.in
@@ -626,8 +626,8 @@ __daylight
__dllonexit
__doserrno
__dstbias
-___fls_getvalue@4@4
-___fls_setvalue@8@8
+ADD_UNDERSCORE(__fls_getvalue@4)
+ADD_UNDERSCORE(__fls_setvalue@8)
__fpecode
__free_locale
__get_current_locale
diff --git a/mingw-w64-crt/lib32/msvcr90.def.in
b/mingw-w64-crt/lib32/msvcr90.def.in
index 4424adfe5..1bc161a5f
Re: [Mingw-w64-public] [PATCH] crt: msvcr70.def.in: Add missing @SIZE suffixes and __CxxCallUnwindVecDtor
On Mon, 15 Apr 2024, Pali Rohár wrote: On Monday 15 April 2024 09:19:09 LIU Hao wrote: 在 2024-04-15 04:52, Pali Rohár 写道: Symbols _assert@4 and abort@4 in all versions of msvcr70.dll have @SIZE suffixes. Without @SIZE suffixes they are only in debug msvcr70d.dll library versions and Itanium msvcr70.dll versions. I think these are kinda false positives. The stdcall suffixes are deduced by gendef from machine code, and are not part of the actual export name. These functions do not return and might have no meaningful RET instructions. Ou. Now I checked export names via objdump and rechecked also via readpe. And both tools say that they are without @SIZE suffix. Checking with objdump won't ever show a @size suffix, and I presume readpe does the same. These functions are exported on the DLL interface as plain "name". When we call them, via a declaration marked as stdcall in C, it does produce a call to the symbol "_name@size" instead of the regular "_name". This information is not visible on the external DLL interface at all. Gendef tries to look at the actual contents of the function, and uses heuristics to guess whether the function uses stdcall or cdecl calling convention. It's not foolproof though, as Liu Hao pointed out. objdump only looks at the DLL export table, and I presume readpe does that as well. So other than that, we can only look at the declarations in C headers. In this case, looking at our own headers might not help if it's not up to date for exactly this msvcrt DLL though, but looking at the corresponding MSVC header might help. (Or just compiling a test C file with the corresponding MSVC version and looking at the generated object file to see what symbol reference it generated.) This doesn't help for undocumented/undeclared private symbols 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] [PATCH] crt: msvcr70.def.in: Add missing @SIZE suffixes and __CxxCallUnwindVecDtor
On Monday 15 April 2024 09:19:09 LIU Hao wrote: > 在 2024-04-15 04:52, Pali Rohár 写道: > > Symbols _assert@4 and abort@4 in all versions of msvcr70.dll have @SIZE > > suffixes. Without @SIZE suffixes they are only in debug msvcr70d.dll > > library versions and Itanium msvcr70.dll versions. > > > > I think these are kinda false positives. The stdcall suffixes are deduced by > gendef from machine code, and are not part of the actual export name. These > functions do not return and might have no meaningful RET instructions. Ou. Now I checked export names via objdump and rechecked also via readpe. And both tools say that they are without @SIZE suffix. Sorry for mistake. I used gendef for all changes which I have done recently. So it would be needed to recheck / revisit all my changes in git. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
