Martell Malone via llvm-dev
2015-Aug-13 06:19 UTC
[llvm-dev] [lld] Alias in COFF short import library.
> > 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>
Rui Ueyama via llvm-dev
2015-Aug-13 06:32 UTC
[llvm-dev] [lld] Alias in COFF short import library.
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/17218768/attachment.html>
Martell Malone via llvm-dev
2015-Aug-13 06:43 UTC
[llvm-dev] [lld] Alias in COFF short import library.
> > 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>