[llvm-dev] [lld] Alias in COFF short import library.
Martell Malone via llvm-dev
llvm-dev at lists.llvm.org
Wed Aug 12 23:43:22 PDT 2015
>
> 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>
More information about the llvm-dev
mailing list