<div dir="ltr"><div><div>After some more digging and creating a few testcases in lld I have narrowed it down to<br><br></div>The fact that dlltool generates <br><br><pre class="aLF-aPX-K0-aPE aLF-aPX-aLK-ayr-auR">Contents of section .idata$7:
 0000 55534552 33322e64 6c6c0000           USER32.dll..<br><br></pre><pre class="aLF-aPX-K0-aPE aLF-aPX-aLK-ayr-auR">Where as lld expects<br><br>Contents of section .idata$6:
 0000 55534552 33322e64 6c6c0000           USER32.dll..<br><br></pre><pre class="aLF-aPX-K0-aPE aLF-aPX-aLK-ayr-auR">I recreated the hello64.test using dlltool for the lib and here is the asm dump of the final exe<br><br>hello64gnu.exe:      file format COFF-x86-64<br><br>Disassembly of section .text:<br>.text:<br>    3000:       ff 25 26 f0 ff ff       jmpq    *-4058(%rip)<br>    3006:       90      nop<br>    3007:       90      nop<br>    3008:       ff 25 26 f0 ff ff       jmpq    *-4058(%rip)<br>    300e:       90      nop<br>    300f:       90      nop<br>    3010:       48 83 ec 28     subq    $40, %rsp<br>    3014:       48 c7 c1 00 00 00 00    movq    $0, %rcx<br>    301b:       48 8d 15 e4 df ff ff    leaq    -8220(%rip), %rdx<br>    3022:       4c 8d 05 d7 df ff ff    leaq    -8233(%rip), %r8<br>    3029:       41 b9 00 00 00 00       movl    $0, %r9d<br>    302f:       e8 d4 ff ff ff  callq   -44<br>    3034:       b9 00 00 00 00  movl    $0, %ecx<br>    3039:       e8 c2 ff ff ff  callq   -62<br><br></pre><pre class="aLF-aPX-K0-aPE aLF-aPX-aLK-ayr-auR">So I am fairly certain this is the cause.<br></pre><br><pre class="aLF-aPX-K0-aPE aLF-aPX-aLK-ayr-auR"><br></pre><pre class="aLF-aPX-K0-aPE aLF-aPX-aLK-ayr-auR">Many Thanks<br></pre><pre class="aLF-aPX-K0-aPE aLF-aPX-aLK-ayr-auR">Martell<br></pre></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 23, 2015 at 4:22 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">I forgot to attach the notes.txt with the objdump.<br><br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 23, 2015 at 3:55 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">Hi again rui, :)<div><br></div><div>I've got all the patches into llvm and clang for supporting mingw-w64 via compiler-rt and now we are able to build a full mingw-w64 toolchain without gcc :)</div><div>With great help from yaron and rnk.</div><div><br></div><div>I've CC'd them as they might have interest in seeing this target through with me to the end :) </div><div><br></div><div>So I have again turned my attention to LLD so that we can also remove ld as a depend for this target </div><div><br></div><div>Previously I raised the issue that while lld would infact link exe's for me the issue was the sections were malformed and thus crashed on launch.</div><div><br></div><div>I've done some debugging reguarding this and discovered it is due to differences between what MSVC's lib.exe and binutils dlltool produces</div><div><br></div><div>I have attached a very simple .def file and generated libs via dlltool along with an objdump -s log of the lib.exe version</div><div><br></div><div>I don't know too much about the internals of lld to be able to tell the exact cause of the problem but there are 3 specific differences I noted.</div><div><br></div><div><div>1. With dlltool each object has the name of a compiled .o file this is the one it generates when building the code section</div><div>With lib each object has the dll name </div><div><br></div><div>2. With dlltool section 7 is used for the dll name and the function names with lib section 6 is used</div><div><br></div><div>3. Other differences are that there is no debug section with dlltool and the text section comes first rather than last with lib (that probably doesn't matter much though)</div></div><div><br></div><div>Please see attached notes.txt with objdump's of both libs</div><div><br></div><div>Can could you give me your thoughts on this and how best we support both layouts in COFF/PECOFF ?</div><div><br></div><div>What source files should I be looking at to patch this or is this something you can support with very little effort ?</div><div><br></div><div>I don't know if you would be opposed to supporting this or not being honest dlltool should generate libs using the same section number as lib.exe but we can't exactly change that now because existing toolchains and libs have already been built with this and changing that would break them.</div><div><br></div><div>If you are opposed I would like you to still tell me what I have to change to get it working after I do that I can narrow the scope for getting a patch up streamed into binutils to fix this :)</div><div><br></div><div>Kind Regards</div><span><font color="#888888"><div>Martell</div></font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>