[llvm-bugs] [Bug 44784] New: LTO failure with mixed DWARF version metadata
via llvm-bugs
llvm-bugs at lists.llvm.org
Tue Feb 4 15:19:44 PST 2020
https://bugs.llvm.org/show_bug.cgi?id=44784
Bug ID: 44784
Summary: LTO failure with mixed DWARF version metadata
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: dmajor at mozilla.com
CC: dblaikie at gmail.com, froydnj at gmail.com,
htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org
Blocks: 44555
While testing the 10.0 release branch, we ran into the following situation:
* We use rustc 1.39 (based on LLVM 9) to build (with LTO) some Rust code, and
the resulting object file has a piece of metadata saying the DWARF version is 2
and the behavior is `llvm::Module::Warning`.
* We use clang 10 to build (with LTO) some C++ code, and the resulting object
file has a piece of metadata saying the DWARF version is 4 and the behavior is
`llvm::Module::Max`, because of the change in [1].
(I don't know why we have mismatched DWARF versions.)
* When we link the objects together, previously we would just get a bunch of
warning spam, but now we fail with an LTO error because of the mismatch in
behaviors [2].
@dblaikie: Is this scenario expected to be supported? From my reading of the
changeset, it sounds like the desired behavior would be to upgrade to the
higher version, and perhaps warn, but not fail the build. So maybe the
mismatched-behaviors check is too aggressive in this case. But correct me if
I've misunderstood the intent. Or maybe it's our fault for using mixed LLVM
versions.
[1]
https://github.com/llvm/llvm-project/commit/e956952edec140d2475aa7c8cbe20fbdd3320634
[2]
https://github.com/llvm/llvm-project/blob/d8117542ac57f6051674ca70ea14c0e0d7d9b046/llvm/lib/Linker/IRMover.cpp#L1280
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=44555
[Bug 44555] [meta] 10.0.0 Release Blockers
--
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/20200204/59027390/attachment.html>
More information about the llvm-bugs
mailing list