[PATCH] D36548: [llvm-dlltool] Fix creating stdcall/fastcall import libraries for i386

[Martell Malone via Phabricator via llvm-commits]

martell added a comment.

In https://reviews.llvm.org/D36548#837716, @mstorsjo wrote:

> When creating an import library as a side effect of linking a DLL, it's fine that the .def file only has got the undecorated name without the @4 suffix, the linker will map it to the real symbol name and export the decorated >symbol name in the import library. (And for link.exe and lld, it sets name type "undecorate", which tells the linker to strip the extra suffix when linking to it, so that the DLL import table only contains the undecorated name. This is what is currently broken though, the name type doesn't get set correctly, that I try to fix here and in https://reviews.llvm.org/D36545.)
> However, when creating an import library from scratch without linking a DLL, the information about what suffixes to use must come from somewhere, so they need to be in the def file. I'm not sure if it's even possible to >create a proper import library for stdcall functions from scratch from a def file with MS link.exe/lib.exe, without having corresponding object files. (If someone knows how to do that, please tell me.) So the extra dlltool ?>behaviour is warranted IMO.


I'm confused to the purpose of the def files created at the time of linking a dll in that case.
Essentially the import library has information that the definition file is missing.
Thus we can not re-create the import library with that definition file, making it useless?

I presume Microsoft do not need to create import libraries from definition files because they have the original libraries create when they actually linked the system dll's
I follow now what you mean by this information needs to stores somewhere, it makes sense to have an extra mode in dlltool for this case.

The only alternative I can think of is a tool that directly creates an import library from a dll without using a definition file, this may be in somewhat related to the question I have above but is not useful for our case because we want to also be able to build the mingw-w64 crt on non windows systems( and support versions of windows outside just the one it was built on).


https://reviews.llvm.org/D36548