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

>
> 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>

Hmm, that's not correct too. All symbols listed in the archive header must
be defined by some member in the archive. In other words, the header is
created just by extracting all external symbols from members. It's not
doable to rename symbol A to B by writing B to the archive file header.

By aliasing, I was suggesting adding an extra object file to an archive
file containing a short import file. The extra object file is to define
aliases to symbols defined by the import library.

Say, you are creating a DLL which defines a function symbol "foo". You
need
to create an import library that defines "foo" and
"__imp_foo". This is
what normal linkers do.

If you want to define an alias symbol "bar" to "foo" (which
is an extension
you want to provide), one way is to create an object file that defines
"bar" and "__imp_bar" as aliases to "foo" and
"__imp_foo", respectively,
and add that object file to the import library. As a result, the import
library file defines four symbols, {,__imp_}{foo,bar}.

Do you know how to define symbol aliases in COFF? If you don't, take a look
a member of oldnames.lib (which comes with MSVC). That library file defines
bunch of aliases, and you can do the same thing.

On Thu, Aug 13, 2015 at 2:25 PM, Martell Malone <martellmalone at
gmail.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.
>
> 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/f1f4a86b/attachment.html>

>
> If you want to define an alias symbol "bar" to "foo"
(which is an
> extension you want to provide), one way is to create an object file that
> defines "bar" and "__imp_bar" as aliases to
"foo" and "__imp_foo",
> respectively, and add that object file to the import library. As a result,
> the import library file defines four symbols, {,__imp_}{foo,bar}.
>
> Do you know how to define symbol aliases in COFF? If you don't, take a
> look a member of oldnames.lib (which comes with MSVC). That library file
> defines bunch of aliases, and you can do the same thing.
>
Thanks for pointing me in the right direction :)

After looking at oldnames.lib I done a little more reading and I assume I
do it like this then for the alias.

The import table points to the functions like this.
__imp_oldfu -> newfun.obi
oldfu -> newfun.obj
I have attached the 2 files named here.

I assume this is what you meant by Weak Externals ?



On Thu, Aug 13, 2015 at 6:36 AM, Rui Ueyama <ruiu at google.com> wrote:
> Hmm, that's not correct too. All symbols listed in the archive header
must
> be defined by some member in the archive. In other words, the header is
> created just by extracting all external symbols from members. It's not
> doable to rename symbol A to B by writing B to the archive file header.
>
> By aliasing, I was suggesting adding an extra object file to an archive
> file containing a short import file. The extra object file is to define
> aliases to symbols defined by the import library.
>
> Say, you are creating a DLL which defines a function symbol
"foo". You
> need to create an import library that defines "foo" and
"__imp_foo". This
> is what normal linkers do.
>
> If you want to define an alias symbol "bar" to "foo"
(which is an
> extension you want to provide), one way is to create an object file that
> defines "bar" and "__imp_bar" as aliases to
"foo" and "__imp_foo",
> respectively, and add that object file to the import library. As a result,
> the import library file defines four symbols, {,__imp_}{foo,bar}.
>
> Do you know how to define symbol aliases in COFF? If you don't, take a
> look a member of oldnames.lib (which comes with MSVC). That library file
> defines bunch of aliases, and you can do the same thing.
>
> On Thu, Aug 13, 2015 at 2:25 PM, Martell Malone <martellmalone at
gmail.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.
>>
>> 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/be389ccc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newfun.obi
Type: application/octet-stream
Size: 180 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150813/be389ccc/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newfun.obj
Type: application/octet-stream
Size: 214 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150813/be389ccc/attachment-0001.obj>