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

Martin Storsjö via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 10 05:36:19 PDT 2017

mstorsjo added a comment.

In https://reviews.llvm.org/D36548#837871, @martell wrote:

> 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?

The main reason for a def file when linking a DLL, is to list which symbols are supposed to be exported. There's a difference between the MS and GNU toolchains here: With MS tools, no symbols are exported by default, unless you list them in a def file, have the symbol definition annotated with `__declspec(dllexport)` or tell the linker to export it with a `/export` argument. So you need to list your symbols (but without decorations, in the form you'd write them in a C file) in the def file.

(A second, older concern for def files is to specify the ordinal for each exported function, in case a caller wants to link to them by ordinal instead of by name. In those cases, the library developer needs to keep the function <-> ordinal mapping constant between releases.)

With GNU toolchains, all global symbols are exported by default. So for using lld as a linker in a mingw world, we'd need to implement this mode as well, but we can leave that until the main mingw driver frontend has been merged.


More information about the llvm-commits mailing list