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
