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

Thu Aug 6 07:58:33 PDT 2015

>
> 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/f704cf1f/attachment.html>