[llvm-bugs] [Bug 36096] New: Regression: Invalid *.lib produced on MSVC upgrading from 4.0.1

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Jan 25 11:52:28 PST 2018


https://bugs.llvm.org/show_bug.cgi?id=36096

            Bug ID: 36096
           Summary: Regression: Invalid *.lib produced on MSVC upgrading
                    from 4.0.1
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Object
          Assignee: unassignedbugs at nondot.org
          Reporter: alex at crichton.co
                CC: llvm-bugs at lists.llvm.org, martellmalone at gmail.com,
                    ruiu at google.com

Created attachment 19750
  --> https://bugs.llvm.org/attachment.cgi?id=19750&action=edit
Object to insert in archive

Over at rust-lang/rust we've been a little slow to the uptick of landing LLVM
changes, but we're getting around now to upgrading from LLVM 4.0.1 to 6.0.0.
Unfortunately though we're seeing what I think is a regression in behavior of
the `llvm-ar.exe` tool on Windows MSVC.

I've run a bisection and it pointed at https://reviews.llvm.org/D29892 so I'm
cc'ing those there to hope that y'all can help out with this issue!
Unfortunately I don't have a small reproduction to gist here but I can
certainly work to make it smaller if need be!

The rust compiler isn't necessarily standard about how it uses LLVM, for
example we don't literally use `llvm-ar.exe` but rather call `writeArchive`
directly. I believe that the various invocations are the same, however, in
terms of reproduction at the command line. 

In any case, the bug that I'm seeing happens when we do something like:

* First we compile a C++ library to an archive using its own build system
(CMake). That project is https://github.com/WebAssembly/binaryen. 
* Next, the Rust compiler opens up this archive using the `Archive` class in
LLVM and iterates over it with `Archive::child_iterator`.
* We then create a new archive with `writeArchive` where some members are
freshly generated object files (aka the Rust code) and the remaining members
are those from the previous `Archive` opened earlier. We're using
`NewArchiveMember::getOldMember` to insert these preexisting members into the
new archive.
* Later this archive that was generated is then passed to `link.exe`, MSVC's
linker
* The bug happens here where MSVC's linker spits out a message "library is
corrupt" (with no other information).

Using LLVM 4.0.1 `link.exe` doesn't spit out this error message, but using LLVM
6.0.0 `link.exe` spits out the error message. 

While I haven't managed to create a tiny test case I have managed to reduce
this somewhat. Specifically I've been taking the object file attached to this
bug and executing:

    llvm-ar.exe crus libfoo.a archive.obj

When the resulting archive is fed to `link.exe` on LLVM 4.0.1 then `link.exe`
spits out a ton of undefined symbol errors (as the archive is missing all the
other objects). On LLVM 6.0.0, however, `link.exe` simply spits out "library is
corrupt". Unfortunately a direct invocation of `link.exe` isn't working, I've
been using it with all the other libraries and files on the originally failing
`link.exe` command. I'm not too familiar with `link.exe`, though, so y'all may
know how to create a more directly failing test case!

Upon running a bisection it ended up pointing at
https://github.com/llvm-mirror/llvm/commit/5d7d0e869f7abea7d1022e4b65a75a97dc2e54a6.
This commit was reverted a few hours later but a slight tweak was relanded and
I believe it's stayed since. The "suspicious" line for archive writing was the
change to `ArchiveWriter.cpp` where `SF_Indirect` symbols were changed to be
included in the archive.

I've tested out LLVM 6.0.0 with just the change to `ArchiveWriter.cpp` reverted
from that patch (aka remove the branch that checks `SF_Indirect`). That seems
to at least restore the old behavior and produces a working archive which isn't
considered corrupt by `link.exe`.

Ok so that's all the information that I currently have at this time, but I
realize it's not a great amount of information as it can't be trivially
reproduced yet! I'm hoping though that y'all cc'd here can help me out and
either recognize what's going on here or suggest a way to help minimize.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180125/52bfd34f/attachment-0001.html>


More information about the llvm-bugs mailing list