[PATCH] D11724: COFF: Add test for ld/section created import library

Thu Aug 6 08:14:17 PDT 2015

Before I let this slip by aswell there is one big issue with switching over
to the implib format for mingw-w64

LIBRARY "user32.dll"
EXPORTS
MessageBoxA == MessageBoxW

dlltool objct format provides us with the option of having an alias.
Can we do this in implib ?

What the above .def means that where MessagBoxW is called it is joined to
MessageBoxA.

On Thu, Aug 6, 2015 at 3:58 PM, Martell Malone <martellmalone at gmail.com>
wrote:

> Yeah, I found that too and it (especially the way how it creates a gap
>> between .idata$3 and .idata$4) looks really hacky. I also found that GNU ld
>> has a special logic to order .idata$<n> sections.
>> At first I thought that I could mimic GNU ld and MSVC linker to generate
>> the .idata section, but seems like it would really mess up the DLL import
>> table generation code. We probably should keep the existing logic
>
> Yeah I don't think copying gnu ld is the way to go, it is a very hacky
> project to say the least :)
>
>
> It feels to me that it makes more sense to add a new option to dlltool to
>> generate short import libraries. It shouldn't be that hard. Martell, what
>> do you think?
>
> I already wrote a replacement tool for this called genlib that will go
> into the mingw-w64 project.
> I want to remove mingw-w64's dependancy on binutils so that we can have a
> clang based toolchain without binutils at all.
> The notion of having dlltool as part of binutils made no sense in the
> first place, It should have been part of mingw to begin with.
> The name was chosen to correlate to on of mingw-w64's other tools called
> gendef which creates the def files from parsing dll's.
> I'm still finalizing the code in this and doing some tests.
>
> I then tried to detect dlltool-style import files and read them as if they
>> were short import libraries, so that I can keep the existing code. That
>> didn't work well because it's not easy to detect dlltool-style import files
>> in a reliable manner without sacrificing performance.
>
> While you might not want to merge because of this into the official
> project because of performance issues it might be something for the
> mingw-w64 users to avail of until ld supports import style libraries.
>
> If you have the patch for this I'd like have a look at it if possible.
> I'd like to try and apply this over the PECOFF for the clang 3.7 package
> in our msys2 distro.
>
> The issue I have is I would have to get approval to switch to using genlib
> instead of dlltool as mingw-w64's default.
> This would not be approved until ld supports implibs and the next version
> of binutils released.
> As you probably well know how things work that could take months to get
> changed over.
> I'd like to use your patch as a base for a temporary stop over until this
> happens
>
> I'm sure the distro users of msys2 won't mind a performance hit until 3.8
> rather then having no support at all.
>
>
>
>
>
> On Wed, Aug 5, 2015 at 10:51 PM, Rui Ueyama <ruiu at google.com> wrote:
>
>> On Mon, Aug 3, 2015 at 10:36 PM, Martell Malone <martellmalone at gmail.com>
>> wrote:
>>
>>> From my reading on how gnuld handles PE/COFF
>>> It uses a linker script that describes how it lays out its idata section.
>>> From i386pe.x
>>>
>>>   .idata BLOCK(__section_alignment__) :
>>>   {
>>>     /* This cannot currently be handled with grouped sections.
>>> 	See pe.em:sort_sections.  */
>>>     SORT(*)(.idata$2)
>>>     SORT(*)(.idata$3)
>>>     /* These zeroes mark the end of the import list.  */
>>>     LONG (0); LONG (0); LONG (0); LONG (0); LONG (0);
>>>     SORT(*)(.idata$4)
>>>     SORT(*)(.idata$5)
>>>     SORT(*)(.idata$6)
>>>     SORT(*)(.idata$7)
>>>   }
>>>
>>>
>> Yeah, I found that too and it (especially the way how it creates a gap
>> between .idata$3 and .idata$4) looks really hacky. I also found that GNU ld
>> has a special logic to order .idata$<n> sections.
>>
>> At first I thought that I could mimic GNU ld and MSVC linker to generate
>> the .idata section, but seems like it would really mess up the DLL import
>> table generation code. We probably should keep the existing logic.
>>
>> I then tried to detect dlltool-style import files and read them as if
>> they were short import libraries, so that I can keep the existing code.
>> That didn't work well because it's not easy to detect dlltool-style import
>> files in a reliable manner without sacrificing performance.
>>
>> It feels to me that it makes more sense to add a new option to dlltool to
>> generate short import libraries. It shouldn't be that hard. Martell, what
>> do you think?
>>
>>> Under ld/emultempl/pep.em in binutils it describes how it converts the MS import library to its format.
>>> see here http://github.com/bminor/binutils-gdb/blob/master/ld/emultempl/pep.em#L1625
>>> From the code in this function and the rest of pep.em we can see how it handles it.
>>> I'm sure this will make more sense to you however as you know what the MS format is.
>>>
>>> I assume the conversion will have to go the other way for us
>>> I think the most notable thing is the use of idata7 instead of idata6 for the dll name
>>> We could use that as a check?
>>> Then hijack it pulling out the function names once we see this being used and insert it into the sections like a MS generated one
>>>
>>> You might have a much cleaner solution however. :)
>>>
>>> If this isn't enough insight into what you need I can do more digging.
>>> Just ping me and let me know
>>>
>>>
>>> On Tue, Aug 4, 2015 at 3:15 AM, Rui Ueyama <ruiu at google.com> wrote:
>>>
>>>> ruiu added a comment.
>>>>
>>>> Do you know anything about how GNU ld handles these import libraries? My
>>>> linker is able to read it and construct .idata section, but the
>>>> resulting
>>>> .idata section is not going to be in correct format. If GNU linker is
>>>> able
>>>> to generate a correct .idata section from this type of import libraries,
>>>> there must be something I'm missing in my linker.
>>>>
>>>>
>>>> http://reviews.llvm.org/D11724
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150806/08da155e/attachment-0001.html>