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

Rui Ueyama via llvm-dev llvm-dev at lists.llvm.org
Thu Aug 13 00:55:00 PDT 2015


This file looks good.

On Thu, Aug 13, 2015 at 3:43 PM, Martell Malone <martellmalone at gmail.com>
wrote:

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


More information about the llvm-dev mailing list