On Thu, 18 Apr 2024, Pali Rohár wrote:
On Friday 19 April 2024 00:22:31 Martin Storsjö wrote:
On Mon, 8 Apr 2024, Pali Rohár wrote:
I386 symbols __CxxLongjmpUnwind, _adj_fdiv_m*, _adj_fdivr_m* and
_seh_longjmp_unwind have @SIZE suffix in I386 version of msvcr80.dll.
I presume this is not a case where the symbols have @size suffixes in the
DLL itself (which does exist but is quite rare), but where they are stdcall
functions and gendef deduces that they should have this suffix, right?
Exactly, now I re-checked it. I sent this patch before you have figured
out that issue.
It might be good to reword this aspect of the commit message a little...
Yes, makes sense. What about?
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.
Thanks, that sounds good.
Also, this adds this suffix for _adj_fdiv_m* - wasn't this the symbol we
checked that really shouldn't have such a suffix?
Yes, that is truth. But as I wrote, I sent this patch before recheck.
I have a fix for all _adj_fdiv_m* symbols in all def files. But I have
it on top of the "Sort symbols" patch. And changing order of these
patches requires nontrivial rebasing of everything...
Right, I guess that's understandable.
I guess we can apply this one then, with a commit message mentioning that
we know that this bit isn't entirely right (practically, it's of course
harmless either way), but it will be fixed in an upcoming commit.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
