<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">It's doable to support dlltool-style import libraries by LLD. .idata sections in dlltool-style libraries are designed so that they will naturally construct the import descriptor table by just sorting them by section name. Supporting them is not hard.</span></blockquote><div><br></div><div>I don't really know my way around the code base of COFF well enough todo this myself.</div><div>If you can point me in the right direction as to what functions/sources to be looking at I think I can come up with a patch.</div><div>If you think you can do it fairly easily I can also create a test case for you if you want ?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">One thing we need to do is that currently we construct the import descriptor directly from short import libraries. We don't create intermediate .idata$X sections from short import libraries. That means we cannot mix dlltool-style and short import libraries at this moment. We need to do something for that. Except that, supporting dlltool-style libraries should be straightforward.</span></blockquote><div> </div><div>This is a very unique scenario and I don't know of any tool that generates both styles of libraries.</div><div>I can create one if we need it for a test case but I think this would be overkill :) </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 25, 2015 at 11:29 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">It's doable to support dlltool-style import libraries by LLD. .idata sections in dlltool-style libraries are designed so that they will naturally construct the import descriptor table by just sorting them by section name. Supporting them is not hard.<div><br></div><div>One thing we need to do is that currently we construct the import descriptor directly from short import libraries. We don't create intermediate .idata$X sections from short import libraries. That means we cannot mix dlltool-style and short import libraries at this moment. We need to do something for that. Except that, supporting dlltool-style libraries should be straightforward.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 25, 2015 at 3:10 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 dir="ltr"><div><div><div><div><div><div><div>Hi Rui,<br><br></div><div>Thanks for getting back to me on this<br></div><div><span><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Do you think that you can make dlltool to generate short import
libraries? If you can, it would be the easiest way to solve the issue.<br></blockquote></span>On my current tests ld seems to not like libraries built with short import libraries so this would require an ABI break in binutils.<br></div><div><br></div><div>dlltool has support for loads of legacy targets and changing this would also possibly break some of those targets so<br></div>Rather than working on dlltool I opted for creating a new tool for mingw-64 to generate libs from def files using the "short import library"<br></div>Another reason for me doing this is to have a complete clang based mingw-w64 toolchain without any gnu gcc or binutils dependencies.<br><br></div>It would be ideal however if we could support what dlltool currently produces in lld.<br></div><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__mingw.org&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=jiZoNJwTOUuY7zeq6lqu6nhe3bSydxcSjzx57nghM5c&s=Ap1VJkiB_VLKtMtYESyX5qP8UEOFN5iLfnxLT7NA8RQ&e=" target="_blank">mingw.org</a> toolchains will not be using the new tool I am creating and every distribution of mingw would have to rebuild their crt's just to work with lld.<br>This isn't ideal when clang is currenly used like a drop in add on for mingw-64 toolchains.<br></div>So if it is an easy enough fix we should support this in lld<br></div><div>Especially when MSVC already does.<br><br></div>Is there much involved with supporting this on the lld end?<br><br></div><div>Many Thanks<span><font color="#888888"><br></font></span></div><span><font color="#888888"><div>Martell<br></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 25, 2015 at 10:38 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Martell,<div><br></div><div>Sorry for the belated response. I missed this email.</div><div><br></div><div>I took a quick look at the library file you have attached and noticed that the file consists of regular object files. LLD expects that all dllimported symbols are described using "short import library" (PE/COFF spec 7). Because I didn't test LLD with dlltool-style archive files, it's no surprise that it didn't work (although it should theoretically work).</div><div><br></div><div>Do you think that you can make dlltool to generate short import libraries? If you can, it would be the easiest way to solve the issue.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Sat, Jul 25, 2015 at 6:23 AM, Martell Malone <span dir="ltr"><<a href="mailto:martellmalone@gmail.com" target="_blank">martellmalone@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi Ivan, :)<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">For testing purposes, I've managed to make the old COFF linker work with a simple test case<br></blockquote><div>Have you got patches for this that I can look at ?<span><br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Had to make two little changes, and link the exe manually, because the linker doesn't understand the GNU flags <br></blockquote></span><div>I've solved the issue of having a GNU driver for the linker so that's not an issue anymore<br></div><div>I sent in patches to the mailing list on this previously :)<br></div><div>I keep them updated over in the msys2 project btw<br></div><div><span><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">By the way, even the MS linker works with the binutils generated import libraries.<br></blockquote></span><div>Yes i assume binutils was based from a very old version of a MS linker which did this layout at the time.<br></div><div>lld is so much newer and the MS linker has been updated to a more modern layout which is why we have this issue<br><br></div><div>Kind Regards<span><font color="#888888"><br></font></span></div><span><font color="#888888"><div>Martell <br></div></font></span></div><div> <br></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 25, 2015 at 12:43 PM, Ivan Garramona <span dir="ltr"><<a href="mailto:heavenandhell171@gmail.com" target="_blank">heavenandhell171@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 dir="ltr"><div>Hi Martell.<br><br></div>I too was trying to make the new COFF linker recognize the libraries generated by binutils, but it wasn't resolving the DLLs, just like you described. Apparently it is not identifying the libraries as import libraries but archives.<br><br>For testing purposes, i've managed to make the old COFF linker work with a simple test case. Had to make two little changes, and link the exe manually, because the linker doesn't understand the GNU flags, but it works. By the way, even the MS linker works with the binutils generated import libraries.<br><br><br></div>
</blockquote></div><br></div>
</div></div><br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>