<html>
    <head>
      <base href="https://bugs.llvm.org/">
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Regressions in written import libraries since 4.0"
   href="https://bugs.llvm.org/show_bug.cgi?id=34181">34181</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>Regressions in written import libraries since 4.0
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>lld
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>unspecified
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>PC
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>enhancement
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>COFF
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>unassignedbugs@nondot.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>martin@martin.st
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>llvm-bugs@lists.llvm.org
          </td>
        </tr></table>
      <p>
        <div>
        <pre>Since the 4.0 release, there are at least two regressions in produced import
libraries for i386:
- Exported stdcall functions on i386 don't get the right "name type" field in
the produced import library. Code that links to the import library succeeds to
link, but fails to run (since it ends up trying to load a function with the
decorated name).
- Functions renamed with /export:foo=bar end up as weak aliases in the import
library, instead of as a normal import library entry (which is the right thing
to do for such cases).

The former is a regression since LLD was switched over to the factorized
COFFImportLibrary functions in LLVM (in SVN r303491, and reapplied in r304573
with another bug fixed).

The latter is a regression since llvm-dlltool extended the COFFImportLibrary
functions to support writing weak aliases.

Fixes for the first of the issues are in review at:
<a href="https://reviews.llvm.org/D36544">https://reviews.llvm.org/D36544</a> (for LLVM)
<a href="https://reviews.llvm.org/D36545">https://reviews.llvm.org/D36545</a> (for LLD)

Fixes for the second of the issues are in review at:
<a href="https://reviews.llvm.org/D36633">https://reviews.llvm.org/D36633</a> (for LLVM)
<a href="https://reviews.llvm.org/D36634">https://reviews.llvm.org/D36634</a> (for LLD)


The former issue also shows similarly in the new llvm-dlltool, with a suggested
fix in review at:
<a href="https://reviews.llvm.org/D36548">https://reviews.llvm.org/D36548</a> (currently approved, but pending the common fix
in <a href="https://reviews.llvm.org/D36544">https://reviews.llvm.org/D36544</a>)</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>