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

Martell Malone via llvm-dev
2015-08-13T06:43:22Z

>
> newfun.obj seems broken -- dumpbin couldn't read.

Dunno how it got malformed.
This one should be valid

On Thu, Aug 13, 2015 at 7:32 AM, Rui Ueyama <ruiu at google.com> wrote:

> newfun.obj seems broken -- dumpbin couldn't read.
>
> On Thu, Aug 13, 2015 at 3:19 PM, Martell Malone <martellmalone at
gmail.com>
> wrote:
>
>> 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 ?
>>
>
> Yes, that's what I meant.
>
>>
>>
>>
>> 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/3beb3b26/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newfun.obj
Type: application/octet-stream
Size: 154 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150813/3beb3b26/attachment-0001.obj>