A PE COFF spec compliant import library generator.
Intended to be used with mingw-w64.
Supports:
PE COFF spec (section 8, Import Library Format)
PE COFF spec (Aux Format 3: Weak Externals)
Differential D29892
ar: add llvm-dlltool support martell on Feb 13 2017, 7:27 AM. Authored by Tokens
Details A PE COFF spec compliant import library generator. Supports:
Diff Detail
Event TimelineComment Actions Updated as per some suggestions from rui:
Originally suggested as std::vector<uint8_t> createImportLibrary(std::vector<ExportSymbol>) The writeArchive function is needed to create this so it is a to file allocation. The MachineType i.e x86, x64, arm, etc The DllName i.e we need the internal name of the dll the functions expect to be found in. So I had to adjust to std::error_code llvm::object::createImportLibrary(StringRef DllName, std::string &Path, std::vector<COFFShortExport> Exports, MachineTypes Machine)
Comment Actions Before taking a look at details, I have a question. This change copies code from LLD to LLVM, but can you move the code instead? If it is a part of the plan and will be done in a follow-up patch, that's OK, but having duplicate code isn't good.
Comment Actions I had planned to do it in a follow-up patch which just removes it from lld and just calls createImportLibrary or if you would prefer we can call llvm-lib directly,
Comment Actions I want to see a patch to remove code from LLD as they should be checked in as a pair with this patch.
Comment Actions I can do that, my question on the parser remains to do this though because that is also mostly shared with lld bar a few tweaks?
Comment Actions That is an unanswered question. You are copying this large code, and if you would fail to find a good way to remove the duplicated code from LLD in a follow-up patch, we'd have two duplicate parsers, which I want to avoid. You want to find a good way to avoid duplication. Comment Actions I think you missed my inline comment and this got out of context Makes sense. I will have a look at using Expected or Error For the Configuration it might be best to add to the parser and have that as part of llvm also because it can mostly be reused for llvm-lib Have you any suggestions on where this would live? I'm looking for an acceptable location to have the .def parser within the llvm code base. Comment Actions Sorry, I don't have a good idea where we should move that code. Probably a few trial-and-error is needed to find the best spot. Comment Actions Are you suggesting we keep all the other duplicate code? If so, I don't think that's a good thing to do. Comment Actions I think he means move it to lib/Support and remove the code from lld. Also I will setup a separate differential to address the duplication concerns you have. Comment Actions Putting this on hold until D32689 gets merged. Comment Actions light update to take D32689 into account. note:
Comment Actions updated to master. Comment Actions Looking for feedback on how to deal with the change to ArchiveWriter.cpp to only impact COFF and not ELF.
Comment Actions updated to master.
Comment Actions Just an additional comment (hope it doesn't delay adding this tool); this functionality is available in lib.exe in the MSVC universe, and via "link.exe -lib" (which iirc is what lib.exe calls). Is it possible to hook this up into lld later as well, in case most of the actual functionality is in libs and not in the dlltool frontend? That at least seems to be the case, so that's good. (I guess I can try to do that myself once the rest of this has landed as well.) Comment Actions Code was already migrated from LLD to LLVM so that LLD, llvm-lib and llvm-dlltool can share the same code base.
Comment Actions Please read your patch throughly again and again to fix all errors of the same kind until you think your patch is perfect. I think I'm pointing out the same errors probably too many times.
Comment Actions removed all the unneeded headers in a cleanup. check-llvm looks good ninja check-llvm Expected Passes : 14861 Expected Failures : 61 Unsupported Tests : 6273 rebuilt mingw-w64 crt with this and tested with LLD /Users/martell/llvm/usr/bin/lld -flavor link -OUT:a.exe /Users/martell/llvm/usr/x86_64-w64-mingw32/lib/crt2.o /Users/martell/llvm/usr/x86_64-w64-mingw32/lib/crtbegin.o hello.o /Users/martell/llvm/usr/x86_64-w64-mingw32/lib/libmingw32.a /Users/martell/llvm/usr/lib/clang/5.0.0/lib/windows/libclang_rt.builtins-x86_64.a /Users/martell/llvm/usr/x86_64-w64-mingw32/lib/libmoldname.a /Users/martell/llvm/usr/x86_64-w64-mingw32/lib/libmingwex.a /Users/martell/llvm/usr/x86_64-w64-mingw32/lib/libmsvcrt.a /Users/martell/llvm/usr/x86_64-w64-mingw32/lib/libadvapi32.a /Users/martell/llvm/usr/x86_64-w64-mingw32/lib/libshell32.a /Users/martell/llvm/usr/x86_64-w64-mingw32/lib/libuser32.a /Users/martell/llvm/usr/x86_64-w64-mingw32/lib/libkernel32.a /Users/martell/llvm/usr/x86_64-w64-mingw32/lib/crtend.o /alternatename:__image_base__=__ImageBase wine a.exe hello world Can we get a LGTM now? :)
Comment Actions rebased on master. Comment Actions I would REALLY like to make the 5.0 window with this. :)
Comment Actions http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/6544 is not happy about this patch.
|
I would use IMAGE_WEAK_EXTERN_SEARCH_ALIAS here instead of the magic number 3.