<div dir="ltr">I took a look at the code. Looks like you need a library to create import library files in LLVM and use that from llvm-dlltool and LLD. Is that what you are planning?</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 13, 2017 at 5:37 PM, Martell Malone <span dir="ltr"><<a href="mailto:martellmalone@gmail.com" target="_blank">martellmalone@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Ohh nice.</div><div>With that method I can support it without upsetting ld users by introducing an api breakage.</div><div class="HOEnZb"><div class="h5"><div><br><div class="gmail_quote"><div>On Tue 14 Feb 2017 at 01:32, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_6251287334065248gmail_msg"><div class="gmail_extra m_6251287334065248gmail_msg"><div class="gmail_quote m_6251287334065248gmail_msg">On Mon, Feb 13, 2017 at 5:26 PM, Peter Collingbourne <span class="m_6251287334065248gmail_msg"><<a href="mailto:peter@pcc.me.uk" class="m_6251287334065248gmail_msg" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_6251287334065248gmail_msg"><div class="gmail_extra m_6251287334065248gmail_msg"><div class="gmail_quote m_6251287334065248gmail_msg"><span class="m_6251287334065248gmail_msg">On Mon, Feb 13, 2017 at 5:20 PM, Rui Ueyama via llvm-dev <span class="m_6251287334065248gmail_msg"><<a href="mailto:llvm-dev@lists.llvm.org" class="m_6251287334065248gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_6251287334065248gmail_msg"><div class="gmail_extra m_6251287334065248gmail_msg"><div class="gmail_quote m_6251287334065248gmail_msg"><span class="m_6251287334065248m_-5454226468440472222m_-473784349637967476gmail- m_6251287334065248gmail_msg">On Mon, Feb 13, 2017 at 4:46 PM, Martell Malone <span class="m_6251287334065248gmail_msg"><<a href="mailto:martellmalone@gmail.com" class="m_6251287334065248gmail_msg" target="_blank">martellmalone@gmail.com</a>></span> wrote:<br class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg"><span class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px" class="m_6251287334065248gmail_msg">No, I meant an even thinner wrapper which textually translates arguments. For example, the wrapper would translates "/out:foo.exe foo.obj" to "-o foo.exe foo.obj" and then call lld::COFFF:link(). It doesn't do anything with Config object nor LinkerDriver::run and have absolutely zero knowledge on the internals of LLD.</span></blockquote></span>Ohh okay I misunderstood.<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"></div><span class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px" class="m_6251287334065248gmail_msg">(Why I'm asking this is because I want to sure that there's no difference between the regular Windows linker and mingw. If all differences are superficial, the command line translator should just work. If not, there's some semantic difference.)</span></blockquote></span><div class="m_6251287334065248gmail_msg">The libraries can be used with MSVC link.exe directly assuming the correct arguments are passed to the linker.<br class="m_6251287334065248gmail_msg">I tested this after creating a working llvm-dlltool.<br class="m_6251287334065248gmail_msg">The only change I had to make to support this was alter ming-w64 crt to change all references from __image_base__ to _ImageBase to support that<br class="m_6251287334065248gmail_msg"></div></div></blockquote><div class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"></div></span><div class="m_6251287334065248gmail_msg">You may be able to define __ImageBase as a weak external symbol to __image_base__. Then, if __ImageBase is not defined, all references against __ImageBase will be resolved using __image_base__.</div></div></div></div></blockquote><div class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"></div></span>Or you could have your wrapper driver pass "/alternatename:__image_base__<wbr>=__ImageBase".</div></div></div></blockquote><div class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"></div></div></div></div><div class="m_6251287334065248gmail_msg"><div class="gmail_extra m_6251287334065248gmail_msg"><div class="gmail_quote m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg">Ah, that's much better indeed.</div></div></div></div><div class="m_6251287334065248gmail_msg"><div class="gmail_extra m_6251287334065248gmail_msg"><div class="gmail_quote m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg"> </div><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_6251287334065248gmail_msg"><div class="gmail_extra m_6251287334065248gmail_msg"><div class="gmail_quote m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg">Peter</div><div class="m_6251287334065248gmail_msg"><div class="m_6251287334065248m_-5454226468440472222h5 m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg"> </div><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_6251287334065248gmail_msg"><div class="gmail_extra m_6251287334065248gmail_msg"><div class="gmail_quote m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg"><div class="m_6251287334065248m_-5454226468440472222m_-473784349637967476gmail-h5 m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg"> </div><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px" class="m_6251287334065248gmail_msg">That should be fine.</span></blockquote><div class="m_6251287334065248gmail_msg">Great </div></div></div><div class="m_6251287334065248m_-5454226468440472222m_-473784349637967476gmail-m_9184680855068766318HOEnZb m_6251287334065248gmail_msg"><div class="m_6251287334065248m_-5454226468440472222m_-473784349637967476gmail-m_9184680855068766318h5 m_6251287334065248gmail_msg"><div class="gmail_extra m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"><div class="gmail_quote m_6251287334065248gmail_msg">On Mon, Feb 13, 2017 at 9:34 PM, Rui Ueyama <span class="m_6251287334065248gmail_msg"><<a href="mailto:ruiu@google.com" class="m_6251287334065248gmail_msg" target="_blank">ruiu@google.com</a>></span> wrote:<br class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_6251287334065248gmail_msg"><div class="gmail_extra m_6251287334065248gmail_msg"><div class="gmail_quote m_6251287334065248gmail_msg"><span class="m_6251287334065248gmail_msg">On Mon, Feb 13, 2017 at 1:16 PM, Martell Malone <span class="m_6251287334065248gmail_msg"><<a href="mailto:martellmalone@gmail.com" class="m_6251287334065248gmail_msg" target="_blank">martellmalone@gmail.com</a>></span> wrote:<br class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_6251287334065248gmail_msg"><span class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px" class="m_6251287334065248gmail_msg">I wonder if it can be a wrapper for LLD/COFF. It can be an in-process wrapper, meaning that you could add a main function for mingw which translates all arguments into the MSVC style and then invoke the COFF linker's main function.</span></blockquote></span><div class="m_6251287334065248gmail_msg">That should work, if I am understanding this correctly I can create an argument parser (probably partially based on the ELF one) then I can set the data in the COFF Config object and call COFF LinkerDriver::run etc directly from that?<br class="m_6251287334065248gmail_msg"></div></div></blockquote><div class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"></div></span><div class="m_6251287334065248gmail_msg">No, I meant an even thinner wrapper which textually translates arguments. For example, the wrapper would translates "/out:foo.exe foo.obj" to "-o foo.exe foo.obj" and then call lld::COFFF:link(). It doesn't do anything with Config object nor LinkerDriver::run and have absolutely zero knowledge on the internals of LLD.</div><div class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"></div><div class="m_6251287334065248gmail_msg">(Why I'm asking this is because I want to sure that there's no difference between the regular Windows linker and mingw. If all differences are superficial, the command line translator should just work. If not, there's some semantic difference.)</div><span class="m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"></div><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg">This proposal is for generally moving code from lld into llvm that could be part of lib.exe / dlltool, what are your thoughts here?</div></div></blockquote><div class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"></div></span><div class="m_6251287334065248gmail_msg">That should be fine.</div><div class="m_6251287334065248gmail_msg"><div class="m_6251287334065248m_-5454226468440472222m_-473784349637967476gmail-m_9184680855068766318m_-5200324340672299442h5 m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg"> </div><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_6251287334065248m_-5454226468440472222m_-473784349637967476gmail-m_9184680855068766318m_-5200324340672299442m_8124882821685386573HOEnZb m_6251287334065248gmail_msg"><div class="m_6251287334065248m_-5454226468440472222m_-473784349637967476gmail-m_9184680855068766318m_-5200324340672299442m_8124882821685386573h5 m_6251287334065248gmail_msg"><div class="gmail_extra m_6251287334065248gmail_msg"><div class="gmail_quote m_6251287334065248gmail_msg">On Mon, Feb 13, 2017 at 8:57 PM, Rui Ueyama <span class="m_6251287334065248gmail_msg"><<a href="mailto:ruiu@google.com" class="m_6251287334065248gmail_msg" target="_blank">ruiu@google.com</a>></span> wrote:<br class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_6251287334065248gmail_msg"><div class="gmail_extra m_6251287334065248gmail_msg"><div class="gmail_quote m_6251287334065248gmail_msg"><span class="m_6251287334065248gmail_msg">On Mon, Feb 13, 2017 at 12:52 PM, Martell Malone <span class="m_6251287334065248gmail_msg"><<a href="mailto:martellmalone@gmail.com" class="m_6251287334065248gmail_msg" target="_blank">martellmalone@gmail.com</a>></span> wrote:<br class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_6251287334065248gmail_msg"><span class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px" class="m_6251287334065248gmail_msg">Also you need to make a change to LLD/COFF to accept GNU command arguments, right? (Looks like you already have that patch locally.)</span></blockquote></span><div class="m_6251287334065248gmail_msg">Yes </div></div></blockquote><div class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"></div></span><div class="m_6251287334065248gmail_msg">I wonder if it can be a wrapper for LLD/COFF. It can be an in-process wrapper, meaning that you could add a main function for mingw which translates all arguments into the MSVC style and then invoke the COFF linker's main function.</div><div class="m_6251287334065248gmail_msg"><div class="m_6251287334065248m_-5454226468440472222m_-473784349637967476gmail-m_9184680855068766318m_-5200324340672299442m_8124882821685386573m_-3014814662209084741h5 m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg"> </div><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg"><span class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px" class="m_6251287334065248gmail_msg">My patch to hack lld into accepting some very basic gnu front end arguments was enough to get all the above working which was enough to develop further.</span></blockquote><div class="m_6251287334065248gmail_msg"> </div></span></div></div><div class="m_6251287334065248m_-5454226468440472222m_-473784349637967476gmail-m_9184680855068766318m_-5200324340672299442m_8124882821685386573m_-3014814662209084741m_5669066401049317507HOEnZb m_6251287334065248gmail_msg"><div class="m_6251287334065248m_-5454226468440472222m_-473784349637967476gmail-m_9184680855068766318m_-5200324340672299442m_8124882821685386573m_-3014814662209084741m_5669066401049317507h5 m_6251287334065248gmail_msg"><div class="gmail_extra m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"><div class="gmail_quote m_6251287334065248gmail_msg">On Mon, Feb 13, 2017 at 8:41 PM, Rui Ueyama <span class="m_6251287334065248gmail_msg"><<a href="mailto:ruiu@google.com" class="m_6251287334065248gmail_msg" target="_blank">ruiu@google.com</a>></span> wrote:<br class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_6251287334065248gmail_msg"><div class="gmail_extra m_6251287334065248gmail_msg"><div class="gmail_quote m_6251287334065248gmail_msg"><span class="m_6251287334065248gmail_msg">On Mon, Feb 13, 2017 at 12:33 PM, Martell Malone <span class="m_6251287334065248gmail_msg"><<a href="mailto:martellmalone@gmail.com" class="m_6251287334065248gmail_msg" target="_blank">martellmalone@gmail.com</a>></span> wrote:<br class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg">Hey Rui, </div><span class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px" class="m_6251287334065248gmail_msg">I wonder how llvm-dlltool would fit in the entire picture of mingw support. I don't think dlltool is the last missing piece. What do you need to do other than that to fully support mingw using LLVM toolchain?</span></blockquote></span><div class="m_6251287334065248gmail_msg">Other then changing `lib/MC/WinCOFFStreamer.cpp` to not use -aligncomm within the EmitCommonSymbol function and a single patch for mingw-w64 itself to pre-populate it's .ctors and .dtors list, so llvm-dlltool is infact the only missing part really.<br class="m_6251287334065248gmail_msg"></div></div></blockquote><div class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"></div></span><div class="m_6251287334065248gmail_msg">Also you need to make a change to LLD/COFF to accept GNU command arguments, right? (Looks like you already have that patch locally.)</div><div class="m_6251287334065248gmail_msg"><div class="m_6251287334065248m_-5454226468440472222m_-473784349637967476gmail-m_9184680855068766318m_-5200324340672299442m_8124882821685386573m_-3014814662209084741m_5669066401049317507m_-6144031273373274431h5 m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg"> </div><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg">This gives us a fully working clang based mingw-w64 C compiler.<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg">C++ and exception handling is a different story.<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg">libc++ is somewhat working with the following test results<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg">Expected Passes    : 2188</div><div class="m_6251287334065248gmail_msg">Expected Failures  : 44</div><div class="m_6251287334065248gmail_msg">Unsupported Tests  : 588</div><div class="m_6251287334065248gmail_msg">Unexpected Failures: 2816</div><br class="m_6251287334065248gmail_msg">I was able to build it with exceptions disabled and I actually managed to bootstrap llvm and clang itself.<br class="m_6251287334065248gmail_msg">It didn't run very well though as you can imagine based on the above tests.<span class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px" class="m_6251287334065248gmail_msg">It's not a performance issue but a code maintenance issue. The initial patches to support mingw was trying to add a new linker driver and a different linkin semantics to the COFF linker which seemed too complicated to me. IIRC, I suggested adding a shim which translates GNU command line arguments to MSVC linker arguments. Didn't it work?</span></blockquote></span>There were just so many differences between link and ld I never followed down that path. I pushed forward with the short import library support based on your later suggestions. My patch to hack lld into accepting some very basic gnu front end arguments was enough to get all the above working which was enough to develop further.<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg">Best,<br class="m_6251287334065248gmail_msg">Martell </div></div><div class="m_6251287334065248m_-5454226468440472222m_-473784349637967476gmail-m_9184680855068766318m_-5200324340672299442m_8124882821685386573m_-3014814662209084741m_5669066401049317507m_-6144031273373274431m_-5833276860864437611HOEnZb m_6251287334065248gmail_msg"><div class="m_6251287334065248m_-5454226468440472222m_-473784349637967476gmail-m_9184680855068766318m_-5200324340672299442m_8124882821685386573m_-3014814662209084741m_5669066401049317507m_-6144031273373274431m_-5833276860864437611h5 m_6251287334065248gmail_msg"><div class="gmail_extra m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"><div class="gmail_quote m_6251287334065248gmail_msg">On Mon, Feb 13, 2017 at 8:08 PM, Rui Ueyama <span class="m_6251287334065248gmail_msg"><<a href="mailto:ruiu@google.com" class="m_6251287334065248gmail_msg" target="_blank">ruiu@google.com</a>></span> wrote:<br class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_6251287334065248gmail_msg"><div class="gmail_extra m_6251287334065248gmail_msg"><div class="gmail_quote m_6251287334065248gmail_msg">Hi Martell,</div><div class="gmail_quote m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"></div><div class="gmail_quote m_6251287334065248gmail_msg">I wonder how llvm-dlltool would fit in the entire picture of mingw support. I don't think dlltool is the last missing piece. What do you need to do other than that to fully support mingw using LLVM toolchain?</div><div class="gmail_quote m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"></div><div class="gmail_quote m_6251287334065248gmail_msg"><span class="m_6251287334065248gmail_msg">On Mon, Feb 13, 2017 at 8:56 AM, Martell Malone via llvm-dev <span class="m_6251287334065248gmail_msg"><<a href="mailto:llvm-dev@lists.llvm.org" class="m_6251287334065248gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br class="m_6251287334065248gmail_msg"><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_6251287334065248gmail_msg">Hey llvm'ers,<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg">I have been working on a dlltool replacement for llvm.<br class="m_6251287334065248gmail_msg">Here is my initial differential <a href="https://reviews.llvm.org/D29892" class="m_6251287334065248gmail_msg" target="_blank">https://reviews.llvm.org/<wbr>D29892</a><br class="m_6251287334065248gmail_msg">It is based on some functionality that already exists in lld.<br class="m_6251287334065248gmail_msg">I added functionality to support, <span style="color:rgb(0,0,0);font-family:"segoe ui","segoe ui web regular","segoe ui symbol",lato,"helvetica neue",helvetica,arial,sans-serif;font-size:13px" class="m_6251287334065248gmail_msg">PE COFF Weak Externals </span>and of course a front end to actually use it.<br class="m_6251287334065248gmail_msg">I believe the work here can also be used for llvm-lib and lessen the load on lld.<br class="m_6251287334065248gmail_msg">I would like some comments about how this could be be structured to live in llvm with a shared code base across lib ar and dlltool.<br class="m_6251287334065248gmail_msg">I also have a section below called "Difference from lib" which is somewhat of a rationale for the tool.<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg">Many Thanks,<br class="m_6251287334065248gmail_msg">Martell<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg">Context<br class="m_6251287334065248gmail_msg"><span style="font-family:sans-serif" class="m_6251287334065248gmail_msg">==========<br class="m_6251287334065248gmail_msg"></span><br class="m_6251287334065248gmail_msg">Awhile back I talked to various llvm'ers about getting mingw-w64 support for lld.<br class="m_6251287334065248gmail_msg">There were a few issues raised but the main issue was that mingw-w64 should try best to comply with the PECOFF spec, adding support for custom sections and various binutils/mingw hacks would impact the performance of the COFF linker and in general is not something that lld should support.<br class="m_6251287334065248gmail_msg"></div></blockquote><div class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"></div></span><div class="m_6251287334065248gmail_msg">It's not a performance issue but a code maintenance issue. The initial patches to support mingw was trying to add a new linker driver and a different linkin semantics to the COFF linker which seemed too complicated to me. IIRC, I suggested adding a shim which translates GNU command line arguments to MSVC linker arguments. Didn't it work?</div><div class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"></div><blockquote class="gmail_quote m_6251287334065248gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_6251287334065248gmail_msg"><div class="m_6251287334065248m_-5454226468440472222m_-473784349637967476gmail-m_9184680855068766318m_-5200324340672299442m_8124882821685386573m_-3014814662209084741m_5669066401049317507m_-6144031273373274431m_-5833276860864437611m_2856333141893705091h5 m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg">Motivation<br class="m_6251287334065248gmail_msg"><span style="font-family:sans-serif" class="m_6251287334065248gmail_msg">==========<br class="m_6251287334065248gmail_msg"></span><br class="m_6251287334065248gmail_msg">The main motivation was because dlltool and ld did not comply with PECOFF Spec.<br class="m_6251287334065248gmail_msg">It has some custom formatting and uses the assembler for some reason to generate import libraries, it did not use the short import library format at all.<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg">There has been many work arounds for the problem this creates such as the creation of the `reimp` tool. Which imports MSVC built libs creates a def and uses dlltool so that the binutils linker can use it.<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg">We should just be using the short import format and the linker should support that.<br class="m_6251287334065248gmail_msg">Thus llvm-dlltool was born.<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg">Difference from lib<br class="m_6251287334065248gmail_msg">===================<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg">Using <span style="color:rgb(0,0,0);font-family:"segoe ui","segoe ui web regular","segoe ui symbol",lato,"helvetica neue",helvetica,arial,sans-serif;font-size:13px" class="m_6251287334065248gmail_msg">PE COFF spec (section 8, Import Library Format) should be self explanatory.<br class="m_6251287334065248gmail_msg">lib.exe is able to accept def files and create libraries using this format.<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg">example<br class="m_6251287334065248gmail_msg"> <br class="m_6251287334065248gmail_msg">  `LIBRARY "user32.dll"<br class="m_6251287334065248gmail_msg">   EXPORTS<br class="m_6251287334065248gmail_msg">   MessageBoxA`<br class="m_6251287334065248gmail_msg"></span><br class="m_6251287334065248gmail_msg">LIB.exe can create a user32.lib with the function MessageBoxA from the above definition.<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg">Mingw-w64 is different MSVC in that we need to compile the runtime.<br class="m_6251287334065248gmail_msg">MS provide us with their crt prebuilt so lib.exe doesn't have support for external function aliasing.<span style="color:rgb(0,0,0);font-family:"segoe ui","segoe ui web regular","segoe ui symbol",lato,"helvetica neue",helvetica,arial,sans-serif;font-size:13px" class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg">We often use aliases for posix naming reasons as well as avoid using the MS version of a function.<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg">example<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"></span><span style="color:rgb(0,0,0);font-family:"segoe ui","segoe ui web regular","segoe ui symbol",lato,"helvetica neue",helvetica,arial,sans-serif;font-size:13px" class="m_6251287334065248gmail_msg">  `LIBRARY "user32.dll"</span><br style="color:rgb(0,0,0);font-family:"segoe ui","segoe ui web regular","segoe ui symbol",lato,"helvetica neue",helvetica,arial,sans-serif;font-size:13px" class="m_6251287334065248gmail_msg"><span style="color:rgb(0,0,0);font-family:"segoe ui","segoe ui web regular","segoe ui symbol",lato,"helvetica neue",helvetica,arial,sans-serif;font-size:13px" class="m_6251287334065248gmail_msg">   EXPORTS</span><br style="color:rgb(0,0,0);font-family:"segoe ui","segoe ui web regular","segoe ui symbol",lato,"helvetica neue",helvetica,arial,sans-serif;font-size:13px" class="m_6251287334065248gmail_msg"><span style="color:rgb(0,0,0);font-family:"segoe ui","segoe ui web regular","segoe ui symbol",lato,"helvetica neue",helvetica,arial,sans-serif;font-size:13px" class="m_6251287334065248gmail_msg">   MessageBoxA<br class="m_6251287334065248gmail_msg"></span><span style="color:rgb(0,0,0);font-family:"segoe ui","segoe ui web regular","segoe ui symbol",lato,"helvetica neue",helvetica,arial,sans-serif;font-size:13px" class="m_6251287334065248gmail_msg">   MessageBoxW==MessageBoxA`<br class="m_6251287334065248gmail_msg"></span><br class="m_6251287334065248gmail_msg">LIB.exe doesn't not have support for this but dlltool does.<br class="m_6251287334065248gmail_msg">The best fit for this within the spec is <span style="color:rgb(0,0,0);font-family:"segoe ui","segoe ui web regular","segoe ui symbol",lato,"helvetica neue",helvetica,arial,sans-serif;font-size:13px" class="m_6251287334065248gmail_msg">PE COFF spec (Aux Format 3: Weak Externals)<br class="m_6251287334065248gmail_msg"></span><br class="m_6251287334065248gmail_msg">Mingw-w64 also uses lib prefix and .a file extensions for the library name so the driver should be different. The above example would be libuser32.a, for when shared and static versions of the same library exist there is the .dll.a variant.<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg">Issues<br class="m_6251287334065248gmail_msg">=======<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg">Like more of the gnu suite dlltool was not designed in one build multi target manner.<br class="m_6251287334065248gmail_msg">We would have to introduce custom arguments to specify the target, "i686", "x86_64", "thumb2pe" etc.<br class="m_6251287334065248gmail_msg">This will most likely break some level of backwards compatibility with the binutils version.<br class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"></div>
<br class="m_6251287334065248gmail_msg"></div></div>______________________________<wbr>_________________<br class="m_6251287334065248gmail_msg">
LLVM Developers mailing list<br class="m_6251287334065248gmail_msg">
<a href="mailto:llvm-dev@lists.llvm.org" class="m_6251287334065248gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a><br class="m_6251287334065248gmail_msg">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" class="m_6251287334065248gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br class="m_6251287334065248gmail_msg">
<br class="m_6251287334065248gmail_msg"></blockquote></div><br class="m_6251287334065248gmail_msg"></div></div>
</blockquote></div><br class="m_6251287334065248gmail_msg"></div>
</div></div></blockquote></div></div></div><br class="m_6251287334065248gmail_msg"></div></div>
</blockquote></div><br class="m_6251287334065248gmail_msg"></div>
</div></div></blockquote></div></div></div><br class="m_6251287334065248gmail_msg"></div></div>
</blockquote></div><br class="m_6251287334065248gmail_msg"></div>
</div></div></blockquote></div></div></div><br class="m_6251287334065248gmail_msg"></div></div>
</blockquote></div><br class="m_6251287334065248gmail_msg"></div>
</div></div></blockquote></div></div></div><br class="m_6251287334065248gmail_msg"></div></div>
<br class="m_6251287334065248gmail_msg">______________________________<wbr>_________________<br class="m_6251287334065248gmail_msg">
LLVM Developers mailing list<br class="m_6251287334065248gmail_msg">
<a href="mailto:llvm-dev@lists.llvm.org" class="m_6251287334065248gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a><br class="m_6251287334065248gmail_msg">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" class="m_6251287334065248gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br class="m_6251287334065248gmail_msg">
<br class="m_6251287334065248gmail_msg"></blockquote></div></div></div><span class="m_6251287334065248m_-5454226468440472222HOEnZb m_6251287334065248gmail_msg"><font color="#888888" class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"><br clear="all" class="m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg"><br class="m_6251287334065248gmail_msg"></div>-- <br class="m_6251287334065248gmail_msg"><div class="m_6251287334065248m_-5454226468440472222m_-473784349637967476gmail_signature m_6251287334065248gmail_msg"><div class="m_6251287334065248gmail_msg">-- <div class="m_6251287334065248gmail_msg">Peter</div></div></div>
</font></span></div></div>
</blockquote></div></div></div></blockquote></div></div>
</div></div></blockquote></div><br></div>