llvm dev - Aug 2015 - [lld] Alias in COFF short import library.

Hi Rui,

I have finished my tool to generate short import libs for mingw-w64.

It works fine with lld for actual symbols.
But it seems lld segfaults when I try to use and an alias as we discussed
before.

I have attached 3 import libraries.
They all only have 1 import function.

libuser32orig.a -> Works fine and only has MessageBoxA

libuser32b.a -> the symbol table has MessageBoxB and __imp_MessageBoxB but
the Import object has MessageBoxA.user32.dll.

This causes a segfault in lld but should link correctly right ?

Additionally I have attached libuser32.a
This is the same as libuser32b.a but the symbol table has MessageBoxA and
__imp_MessageBoxB rather then MessageBoxB and __imp_MessageBoxB

This also segfaults I assume due to the same bug.

The reason I created this iteration is because we should be able to in the
import library just add extra __imp_{alias} to the symbol tables that point
to the original import of MessageBoxA.

Other then alias support the only difference between my new tool and
lib.exe is that I don't bother to create .debug sections as we don't
need
them.

Kind Regards
Martell
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150813/a4daade7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libuser32orig.a
Type: application/octet-stream
Size: 1394 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150813/a4daade7/attachment.a>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libuser32b.a
Type: application/octet-stream
Size: 1394 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150813/a4daade7/attachment-0001.a>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libuser32.a
Type: application/octet-stream
Size: 1394 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150813/a4daade7/attachment-0002.a>

The header of libuser32b.a says that it defines MessageBoxB and
__imp_MessageBoxB, but the import library file in the archive actually
defines MessageBoxA (not B). So the archive file is broken. You may want to
fix the header and try again.


On Thu, Aug 13, 2015 at 2:04 PM, Martell Malone <martellmalone at
gmail.com>
wrote:
> Hi Rui,
>
> I have finished my tool to generate short import libs for mingw-w64.
>
> It works fine with lld for actual symbols.
> But it seems lld segfaults when I try to use and an alias as we discussed
> before.
>
> I have attached 3 import libraries.
> They all only have 1 import function.
>
> libuser32orig.a -> Works fine and only has MessageBoxA
>
> libuser32b.a -> the symbol table has MessageBoxB and __imp_MessageBoxB
but
> the Import object has MessageBoxA.user32.dll.
>
> This causes a segfault in lld but should link correctly right ?
>
> Additionally I have attached libuser32.a
> This is the same as libuser32b.a but the symbol table has MessageBoxA and
> __imp_MessageBoxB rather then MessageBoxB and __imp_MessageBoxB
>
> This also segfaults I assume due to the same bug.
>
> The reason I created this iteration is because we should be able to in the
> import library just add extra __imp_{alias} to the symbol tables that point
> to the original import of MessageBoxA.
>
> Other then alias support the only difference between my new tool and
> lib.exe is that I don't bother to create .debug sections as we
don't need
> them.
>
> Kind Regards
> Martell
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150813/b01afd82/attachment.html>

>
> The header of libuser32b.a says that it defines MessageBoxB and
> __imp_MessageBoxB, but the import library file in the archive actually
> defines MessageBoxA (not B). So the archive file is broken. You may want to
> fix the header and try again.
Yes this is how I done the alias.

If you consider this invalid then look at libuser32.a
The header defines MessageBoxA and __imp_MessageBoxB.
This should be valid yes ?


On Thu, Aug 13, 2015 at 6:19 AM, Rui Ueyama <ruiu at google.com> wrote:
> The header of libuser32b.a says that it defines MessageBoxB and
> __imp_MessageBoxB, but the import library file in the archive actually
> defines MessageBoxA (not B). So the archive file is broken. You may want to
> fix the header and try again.
>
>
> On Thu, Aug 13, 2015 at 2:04 PM, Martell Malone <martellmalone at
gmail.com>
> wrote:
>
>> Hi Rui,
>>
>> I have finished my tool to generate short import libs for mingw-w64.
>>
>> It works fine with lld for actual symbols.
>> But it seems lld segfaults when I try to use and an alias as we
discussed
>> before.
>>
>> I have attached 3 import libraries.
>> They all only have 1 import function.
>>
>> libuser32orig.a -> Works fine and only has MessageBoxA
>>
>> libuser32b.a -> the symbol table has MessageBoxB and
__imp_MessageBoxB
>> but the Import object has MessageBoxA.user32.dll.
>>
>> This causes a segfault in lld but should link correctly right ?
>>
>> Additionally I have attached libuser32.a
>> This is the same as libuser32b.a but the symbol table has MessageBoxA
and
>> __imp_MessageBoxB rather then MessageBoxB and __imp_MessageBoxB
>>
>> This also segfaults I assume due to the same bug.
>>
>> The reason I created this iteration is because we should be able to in
>> the import library just add extra __imp_{alias} to the symbol tables
that
>> point to the original import of MessageBoxA.
>>
>> Other then alias support the only difference between my new tool and
>> lib.exe is that I don't bother to create .debug sections as we
don't need
>> them.
>>
>> Kind Regards
>> Martell
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150813/aaed3c90/attachment.html>