Martell Malone
2015-Jul-23 14:55 UTC
[LLVMdev] [LLD] support for dlltool generated libs in COFF/PECOFF
Hi again rui, :) 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 :) With great help from yaron and rnk. I've CC'd them as they might have interest in seeing this target through with me to the end :) So I have again turned my attention to LLD so that we can also remove ld as a depend for this target 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. I've done some debugging reguarding this and discovered it is due to differences between what MSVC's lib.exe and binutils dlltool produces I have attached a very simple .def file and generated libs via dlltool along with an objdump -s log of the lib.exe version 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. 1. With dlltool each object has the name of a compiled .o file this is the one it generates when building the code section With lib each object has the dll name 2. With dlltool section 7 is used for the dll name and the function names with lib section 6 is used 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) Please see attached notes.txt with objdump's of both libs Can could you give me your thoughts on this and how best we support both layouts in COFF/PECOFF ? What source files should I be looking at to patch this or is this something you can support with very little effort ? 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. 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 :) Kind Regards Martell -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150723/3ebde4d7/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: libuser32.a Type: application/octet-stream Size: 2880 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150723/3ebde4d7/attachment.a> -------------- next part -------------- A non-text attachment was scrubbed... Name: user32.def Type: application/octet-stream Size: 53 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150723/3ebde4d7/attachment.obj>
Martell Malone
2015-Jul-23 15:22 UTC
[LLVMdev] [LLD] support for dlltool generated libs in COFF/PECOFF
I forgot to attach the notes.txt with the objdump. On Thu, Jul 23, 2015 at 3:55 PM, Martell Malone <martellmalone at gmail.com> wrote:> Hi again rui, :) > > 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 :) > With great help from yaron and rnk. > > I've CC'd them as they might have interest in seeing this target through > with me to the end :) > > So I have again turned my attention to LLD so that we can also remove ld > as a depend for this target > > 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. > > I've done some debugging reguarding this and discovered it is due to > differences between what MSVC's lib.exe and binutils dlltool produces > > I have attached a very simple .def file and generated libs via dlltool > along with an objdump -s log of the lib.exe version > > 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. > > 1. With dlltool each object has the name of a compiled .o file this is the > one it generates when building the code section > With lib each object has the dll name > > 2. With dlltool section 7 is used for the dll name and the function names > with lib section 6 is used > > 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) > > Please see attached notes.txt with objdump's of both libs > > Can could you give me your thoughts on this and how best we support both > layouts in COFF/PECOFF ? > > What source files should I be looking at to patch this or is this > something you can support with very little effort ? > > 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. > > 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 :) > > Kind Regards > Martell >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150723/8a676e7c/attachment.html> -------------- next part -------------- There are 3 differences I can see from the 2 libs 1. With dlltool each object has the name of a compiled .o file this is the one it generates when building the code section With lib each object has the dll name 2. With dlltool section 7 is used for the dll name and the function names with lib section 6 is used 3. Other differences are that there is no debug section with dlltool and the text section comes first rather than last with lib llvm-objdump doesn't work on the msvc lib because it doesn't recogonise the machine type (0x14c) which means it is intel x86 target luckily this is handled in binutils however :) I'll submit a patch to llvm to fix all 4 targets for this x86 x64 arm and aarch64 Here are the 2 outputs from objdump $ llvm-objdump -s libuser32.a dykgt.o: file format COFF-i386 Contents of section .idata$4: 0000 00000000 .... Contents of section .idata$5: 0000 00000000 .... Contents of section .idata$7: 0000 55534552 33322e64 6c6c0000 USER32.dll.. dykgh.o: file format COFF-i386 Contents of section .idata$2: 0000 00000000 00000000 00000000 00000000 ................ 0010 00000000 .... dykgs00001.o: file format COFF-i386 Contents of section .text: 0000 ff250000 00009090 .%...... Contents of section .idata$7: 0000 00000000 .... Contents of section .idata$5: 0000 00000000 .... Contents of section .idata$4: 0000 00000000 .... Contents of section .idata$6: 0000 01004d65 73736167 65426f78 5700 ..MessageBoxW. dykgs00000.o: file format COFF-i386 Contents of section .text: 0000 ff250000 00009090 .%...... Contents of section .idata$7: 0000 00000000 .... Contents of section .idata$5: 0000 00000000 .... Contents of section .idata$4: 0000 00000000 .... Contents of section .idata$6: 0000 00004d65 73736167 65426f78 4100 ..MessageBoxA. $ objdump -s user32.lib In archive user32.lib: USER32.dll: file format pe-i386 Contents of section .debug$S: 0000 02000000 11000900 00000000 0a555345 .............USE 0010 5233322e 646c6c27 00131007 00000003 R32.dll'........ 0020 00000000 0000000c 0000007d 79124d69 ...........}y.Mi 0030 63726f73 6f667420 28522920 4c494e4b crosoft (R) LINK Contents of section .idata$2: 0000 00000000 00000000 00000000 00000000 ................ 0010 00000000 .... Contents of section .idata$6: 0000 55534552 33322e64 6c6c0000 USER32.dll.. USER32.dll: file format pe-i386 Contents of section .debug$S: 0000 02000000 11000900 00000000 0a555345 .............USE 0010 5233322e 646c6c27 00131007 00000003 R32.dll'........ 0020 00000000 0000000c 0000007d 79124d69 ...........}y.Mi 0030 63726f73 6f667420 28522920 4c494e4b crosoft (R) LINK Contents of section .idata$3: 0000 00000000 00000000 00000000 00000000 ................ 0010 00000000 .... USER32.dll: file format pe-i386 Contents of section .debug$S: 0000 02000000 11000900 00000000 0a555345 .............USE 0010 5233322e 646c6c27 00131007 00000003 R32.dll'........ 0020 00000000 0000000c 0000007d 79124d69 ...........}y.Mi 0030 63726f73 6f667420 28522920 4c494e4b crosoft (R) LINK Contents of section .idata$5: 0000 00000000 .... Contents of section .idata$4: 0000 00000000 .... USER32.dll: file format pei-i386 Contents of section .idata$4: 0000 00000000 .... Contents of section .idata$5: 0000 00000000 .... Contents of section .idata$6: 0000 00004d65 73736167 65426f78 41000000 ..MessageBoxA... Contents of section .text: 0000 ff250000 00009090 .%...... USER32.dll: file format pei-i386 Contents of section .idata$4: 0000 00000000 .... Contents of section .idata$5: 0000 00000000 .... Contents of section .idata$6: 0000 01004d65 73736167 65426f78 57000000 ..MessageBoxW... Contents of section .text: 0000 ff250000 00009090 .%......
Martell Malone
2015-Jul-24 09:52 UTC
[LLVMdev] [LLD] support for dlltool generated libs in COFF/PECOFF
After some more digging and creating a few testcases in lld I have narrowed
it down to
The fact that dlltool generates
Contents of section .idata$7:
0000 55534552 33322e64 6c6c0000 USER32.dll..
Where as lld expects
Contents of section .idata$6:
0000 55534552 33322e64 6c6c0000 USER32.dll..
I recreated the hello64.test using dlltool for the lib and here is the
asm dump of the final exe
hello64gnu.exe: file format COFF-x86-64
Disassembly of section .text:
.text:
3000: ff 25 26 f0 ff ff jmpq *-4058(%rip)
3006: 90 nop
3007: 90 nop
3008: ff 25 26 f0 ff ff jmpq *-4058(%rip)
300e: 90 nop
300f: 90 nop
3010: 48 83 ec 28 subq $40, %rsp
3014: 48 c7 c1 00 00 00 00 movq $0, %rcx
301b: 48 8d 15 e4 df ff ff leaq -8220(%rip), %rdx
3022: 4c 8d 05 d7 df ff ff leaq -8233(%rip), %r8
3029: 41 b9 00 00 00 00 movl $0, %r9d
302f: e8 d4 ff ff ff callq -44
3034: b9 00 00 00 00 movl $0, %ecx
3039: e8 c2 ff ff ff callq -62
So I am fairly certain this is the cause.
Many Thanks
Martell
On Thu, Jul 23, 2015 at 4:22 PM, Martell Malone <martellmalone at
gmail.com>
wrote:
> I forgot to attach the notes.txt with the objdump.
>
>
> On Thu, Jul 23, 2015 at 3:55 PM, Martell Malone <martellmalone at
gmail.com>
> wrote:
>
>> Hi again rui, :)
>>
>> 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 :)
>> With great help from yaron and rnk.
>>
>> I've CC'd them as they might have interest in seeing this
target through
>> with me to the end :)
>>
>> So I have again turned my attention to LLD so that we can also remove
ld
>> as a depend for this target
>>
>> 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.
>>
>> I've done some debugging reguarding this and discovered it is due
to
>> differences between what MSVC's lib.exe and binutils dlltool
produces
>>
>> I have attached a very simple .def file and generated libs via dlltool
>> along with an objdump -s log of the lib.exe version
>>
>> 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.
>>
>> 1. With dlltool each object has the name of a compiled .o file this is
>> the one it generates when building the code section
>> With lib each object has the dll name
>>
>> 2. With dlltool section 7 is used for the dll name and the function
names
>> with lib section 6 is used
>>
>> 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)
>>
>> Please see attached notes.txt with objdump's of both libs
>>
>> Can could you give me your thoughts on this and how best we support
both
>> layouts in COFF/PECOFF ?
>>
>> What source files should I be looking at to patch this or is this
>> something you can support with very little effort ?
>>
>> 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.
>>
>> 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 :)
>>
>> Kind Regards
>> Martell
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150724/af052fa0/attachment.html>
Apparently Analagous Threads
- [LLVMdev] [LLD] support for dlltool generated libs in COFF/PECOFF
- [LLVMdev] [LLD] support for dlltool generated libs in COFF/PECOFF
- [LLVMdev] [LLD] support for dlltool generated libs in COFF/PECOFF
- [LLVMdev] [LLD] support for dlltool generated libs in COFF/PECOFF
- [LLVMdev] [LLD] support for dlltool generated libs in COFF/PECOFF