<div dir="ltr">Are you talking about Weak Externals (which is described in 4.5.3 Auxiliry Format 3)? If so, yes, I think we can use that to define aliases.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 7, 2015 at 1:38 PM, Martell Malone <span dir="ltr"><<a href="mailto:martellmalone@gmail.com" target="_blank">martellmalone@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi Rui,</p>
<p dir="ltr">Just a follow up message on the alias name support.</p>
<p dir="ltr">I seem to have found a decent way to support this.</p>
<p dir="ltr">Rather then creating a separate object with stub code and adding it to the lib I was able to just add another short import library and for the relocation record change the value of __imp__MessageBoxA to __imp__Myaliasfunctionname.</p>
<p dir="ltr">The actual import object data still contains _MessageBoxA user32.DLL</p>
<p dir="ltr">This seems to work and MSVC accepts this method of aliasing.</p>
<p dir="ltr">Do you think this is a much better way to go then adding an extra object with stub code?</p>
<p dir="ltr">Cheers<span class="HOEnZb"><font color="#888888"><br>
Martell</font></span></p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On 6 Aug 2015 18:13, "Martell Malone" <<a href="mailto:martellmalone@gmail.com" target="_blank">martellmalone@gmail.com</a>> wrote:<br type="attribution"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">I believe you already have a DLL and want to create an import library for that DLL. If so, it's too late to define an alias because exported symbols from the DLL are already fixed.</span></blockquote><div><br></div></div>Yes after testing an actual importlib I found this to be true.<div><br><div>This must also be the reason why the syntax in dlltool is "==" and not "="</div><div>Because it is not in the spec of .def files from MS.</div><div><br></div><div>Thanks for clarifying that Rui</div><div> </div></div></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 5:57 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Thu, Aug 6, 2015 at 9:51 AM, Martell Malone <span dir="ltr"><<a href="mailto:martellmalone@gmail.com" target="_blank">martellmalone@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><a href="https://msdn.microsoft.com/en-us/library/hyx1zcd3.aspx?f=255&MSPPError=-2147217396" target="_blank">https://msdn.microsoft.com/en-us/library/hyx1zcd3.aspx?f=255&MSPPError=-2147217396</a><br></div><div><br></div><div>Apparently lib supports alias names for the symbol ?</div><div><br></div><div>You sure implib doesn't support this?</div></div></blockquote><div><br></div></span><div>That directive can be used when you are creating both DLL and import library.</div><div><br></div><div>If you export a symbol from a DLL using "EXPORT foo=bar", the linker puts "foo" to the DLL's export table -- and no trace of "bar" is left. This feature is useful if you want to export a function "bar" as "foo" from a DLL.</div><div><br></div><div>I think that's different from what you are trying to do. I believe you already have a DLL and want to create an import library for that DLL. If so, it's too late to define an alias because exported symbols from the DLL are already fixed.</div><div><div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 5:46 PM, Martell Malone <span dir="ltr"><<a href="mailto:martellmalone@gmail.com" target="_blank">martellmalone@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Okay I will continue with the genlib tool then.<div>I will abandon this revision and create a new one once I have a library with the alias coff obj included.</div><div><br></div><div>Thanks for the help</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 5:39 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Thu, Aug 6, 2015 at 9:32 AM, Martell Malone <span dir="ltr"><<a href="mailto:martellmalone@gmail.com" target="_blank">martellmalone@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Yeah I thought the same thing would b true.</div>Okay I'll start working towards this then for the gendef tool.<div>Did you know that llvm-objdump can't dump implib sections btw ?</div><div>I started working on a patch for that.</div><div>I'll add you as a subscriber when I send in the fix<br><div><br></div><div><br></div><div>Would you be able to send me the patch you have for dll style libs ?</div></div></div></blockquote><div><br></div></span><div>I don't have a patch for that. My idea was identifying dlltool-style import library by the existence of ".idata$7" section (because only the GNU extension uses that section) and create a ImportFile for that file, but as that was too hacky, I didn't actually write code for that.</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks again for the help Rui</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 5:28 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Thu, Aug 6, 2015 at 9:24 AM, Martell Malone <span dir="ltr"><<a href="mailto:martellmalone@gmail.com" target="_blank">martellmalone@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">On second thought, we don't have to solve that only with the import library. You can create a (regular) COFF object containing a thunk for an aliased function, and include that object file to a .lib, no?</span></blockquote></span><div>Yes that seems like a good solution to this problem I might be able to add something to the genlib tool to support this.</div><div>I might have to mockup one for yaml2obj.</div><div>Can we have a regular coff object in the same lib as an implib ?</div></div></blockquote><div><br></div></span><div>I believe so -- the import library is just a regular ar file (.lib file) after all and there's no special bit or something that distinguishes import libraries and other .lib files, but you may want to try if in doubt. You can add a regular COFF file to an existing import library using lib command.</div><div><div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 5:17 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On second thought, we don't have to solve that only with the import library. You can create a (regular) COFF object containing a thunk for an aliased function, and include that object file to a .lib, no?</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 8:22 AM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I don't think the short import library supports that. With that you can undecorate names, but AFAIK you cannot define arbitrary aliases for dllexported symbols. Does mingw-w64 heavily relies on that feature?</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 8:14 AM, Martell Malone <span dir="ltr"><<a href="mailto:martellmalone@gmail.com" target="_blank">martellmalone@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Before I let this slip by aswell there is one big issue with switching over to the implib format for mingw-w64<div><br></div><div><div>LIBRARY "user32.dll"</div><div>EXPORTS</div><div>MessageBoxA == MessageBoxW</div></div><div><br></div><div>dlltool objct format provides us with the option of having an alias.</div><div>Can we do this in implib ?</div><div><br></div><div>What the above .def means that where MessagBoxW is called it is joined to MessageBoxA.</div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 3:58 PM, Martell Malone <span dir="ltr"><<a href="mailto:martellmalone@gmail.com" target="_blank">martellmalone@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote">Yeah, I found that too and it (especially the way how it creates a gap between .idata$3 and .idata$4) looks really hacky. I also found that GNU ld has a special logic to order .idata$<n> sections.<br>At first I thought that I could mimic GNU ld and MSVC linker to generate the .idata section, but seems like it would really mess up the DLL import table generation code. We probably should keep the existing logic</blockquote></span><div>Yeah I don't think copying gnu ld is the way to go, it is a very hacky project to say the least :)</div><div><br></div><div><br></div><div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">It feels to me that it makes more sense to add a new option to dlltool to generate short import libraries. It shouldn't be that hard. Martell, what do you think?</span></blockquote></span><div>I already wrote a replacement tool for this called genlib that will go into the mingw-w64 project.</div><div>I want to remove mingw-w64's dependancy on binutils so that we can have a clang based toolchain without binutils at all.</div><div>The notion of having dlltool as part of binutils made no sense in the first place, It should have been part of mingw to begin with.</div><div>The name was chosen to correlate to on of mingw-w64's other tools called gendef which creates the def files from parsing dll's.<br></div></div><div>I'm still finalizing the code in this and doing some tests.</div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">I then tried to detect dlltool-style import files and read them as if they were short import libraries, so that I can keep the existing code. That didn't work well because it's not easy to detect dlltool-style import files in a reliable manner without sacrificing performance.</span></blockquote></span><div>While you might not want to merge because of this into the official project because of performance issues it might be something for the mingw-w64 users to avail of until ld supports import style libraries.</div><div><br></div><div><div>If you have the patch for this I'd like have a look at it if possible.</div></div><div><div>I'd like to try and apply this over the PECOFF for the clang 3.7 package in our msys2 distro.</div><div><br></div><div>The issue I have is I would have to get approval to switch to using genlib instead of dlltool as mingw-w64's default.</div></div><div>This would not be approved until ld supports implibs and the next version of binutils released.</div><div>As you probably well know how things work that could take months to get changed over.</div><div>I'd like to use your patch as a base for a temporary stop over until this happens</div><div><br></div><div>I'm sure the distro users of msys2 won't mind a performance hit until 3.8 rather then having no support at all.</div><div><br></div><div><br></div><div><br></div><div> </div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 5, 2015 at 10:51 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Mon, Aug 3, 2015 at 10:36 PM, Martell Malone <span dir="ltr"><<a href="mailto:martellmalone@gmail.com" target="_blank">martellmalone@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">From my reading on how gnuld handles PE/COFF<div>It uses a linker script that describes how it lays out its idata section.</div><div>From i386pe.x</div><div><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">  .idata BLOCK(__section_alignment__) :
  {
    /* This cannot currently be handled with grouped sections.
        See pe.em:sort_sections.  */
    SORT(*)(.idata$2)
    SORT(*)(.idata$3)
    /* These zeroes mark the end of the import list.  */
    LONG (0); LONG (0); LONG (0); LONG (0); LONG (0);
    SORT(*)(.idata$4)
    SORT(*)(.idata$5)
    SORT(*)(.idata$6)
    SORT(*)(.idata$7)
  }</pre></div></div></blockquote><div><br></div></span><div>Yeah, I found that too and it (especially the way how it creates a gap between .idata$3 and .idata$4) looks really hacky. I also found that GNU ld has a special logic to order .idata$<n> sections.</div><div><br></div><div>At first I thought that I could mimic GNU ld and MSVC linker to generate the .idata section, but seems like it would really mess up the DLL import table generation code. We probably should keep the existing logic.</div><div><br></div><div>I then tried to detect dlltool-style import files and read them as if they were short import libraries, so that I can keep the existing code. That didn't work well because it's not easy to detect dlltool-style import files in a reliable manner without sacrificing performance.</div><div><br></div><div>It feels to me that it makes more sense to add a new option to dlltool to generate short import libraries. It shouldn't be that hard. Martell, what do you think?</div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><pre style="word-wrap:break-word"><div style="color:rgb(34,34,34);white-space:normal;font-family:arial,sans-serif">Under ld/emultempl/pep.em in binutils it describes how it converts the MS import library to its format.</div><div><font face="arial, sans-serif"><span style="white-space:normal">see here <a href="http://github.com/bminor/binutils-gdb/blob/master/ld/emultempl/pep.em#L1625" target="_blank">http://github.com/bminor/binutils-gdb/blob/master/ld/emultempl/pep.em#L1625</a><br></span></font></div><div style="color:rgb(34,34,34);white-space:normal;font-family:arial,sans-serif">From the code in this function and the rest of pep.em we can see how it handles it.</div><div style="color:rgb(34,34,34);white-space:normal;font-family:arial,sans-serif">I'm sure this will make more sense to you however as you know what the MS format is.</div><div style="color:rgb(34,34,34);white-space:normal;font-family:arial,sans-serif"><br></div><div style="color:rgb(34,34,34);white-space:normal;font-family:arial,sans-serif">I assume the conversion will have to go the other way for us</div><div style="color:rgb(34,34,34);white-space:normal;font-family:arial,sans-serif">I think the most notable thing is the use of idata7 instead of idata6 for the dll name</div><div style="color:rgb(34,34,34);white-space:normal;font-family:arial,sans-serif">We could use that as a check?</div><div style="color:rgb(34,34,34);white-space:normal;font-family:arial,sans-serif">Then hijack it pulling out the function names once we see this being used and insert it into the sections like a MS generated one</div><div style="color:rgb(34,34,34);white-space:normal;font-family:arial,sans-serif"><br></div><div style="color:rgb(34,34,34);white-space:normal;font-family:arial,sans-serif">You might have a much cleaner solution however. :)</div><div style="color:rgb(34,34,34);white-space:normal;font-family:arial,sans-serif"><br></div><div style="color:rgb(34,34,34);white-space:normal;font-family:arial,sans-serif">If this isn't enough insight into what you need I can do more digging.</div><div style="color:rgb(34,34,34);white-space:normal;font-family:arial,sans-serif">Just ping me and let me know</div></pre></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 4, 2015 at 3:15 AM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ruiu added a comment.<br>
<br>
Do you know anything about how GNU ld handles these import libraries? My<br>
linker is able to read it and construct .idata section, but the resulting<br>
.idata section is not going to be in correct format. If GNU linker is able<br>
to generate a correct .idata section from this type of import libraries,<br>
there must be something I'm missing in my linker.<br>
<br>
<br>
<a href="http://reviews.llvm.org/D11724" rel="noreferrer" target="_blank">http://reviews.llvm.org/D11724</a><br>
<br>
<br>
<br>
</blockquote></div><br></div>
</div></div></blockquote></span></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</div></blockquote></div>
</div></div></blockquote></div><br></div>