Your message dated Tue, 20 Mar 2018 18:52:00 +0000
with message-id <[email protected]>
and subject line Bug#890401: fixed in llvm-toolchain-5.0 1:5.0.1-3
has caused the Debian Bug report #890401,
regarding llvm-toolchain-4.0: Please include patch to fix code generation on
sparc64
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
890401: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890401
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: llvm-toolchain-4.0
Version: 1:4.0.1-10
Severity: normal
Tags: patch
User: [email protected]
Usertags: sparc64
Hello!
In order to get the Rust compiler work on sparc64, we need another
LLVM patch which is currently being upstreamed [1] which fixes the
code generation on sparc64.
Without the patch, LLVM generates invalid code that binutils stumbles
over and crashes with an internal error [2]. With the patch merged,
LLVM is working properly and allows a full native build of the Rust
compiler on sparc64 :).
Since Rust upstream is currently still on LLVM 4.0, even for Rust
1.24, it would be nice to have the patch merged for the 4.0 version
as well as the 6.0 version of the llvm-toolchain package. Although
we are going to convince upstream to backport the patch for 6.0.
Thanks,
Adrian
> [1] https://reviews.llvm.org/D43271
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=22832
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Description: [Sparc] Include __tls_get_addr in symbol table for TLS calls to it
Global Dynamic and Local Dynamic call relocations only implicitly
reference __tls_get_addr, but it still needs to be in the symbol table
to be bound at link time otherwise it fails to link. For details, see
https://sourceware.org/bugzilla/show_bug.cgi?id=22832.
Author: James Clarke <[email protected]>
Last-Update: 2018-02-14
--- llvm-toolchain-4.0-4.0.1.orig/lib/Target/Sparc/MCTargetDesc/SparcMCExpr.cpp
+++ llvm-toolchain-4.0-4.0.1/lib/Target/Sparc/MCTargetDesc/SparcMCExpr.cpp
@@ -194,14 +194,30 @@ static void fixELFSymbolsInTLSFixupsImpl
void SparcMCExpr::fixELFSymbolsInTLSFixups(MCAssembler &Asm) const {
switch(getKind()) {
default: return;
+ case VK_Sparc_TLS_GD_CALL:
+ case VK_Sparc_TLS_LDM_CALL: {
+ // The corresponding relocations reference __tls_get_addr, as they call it,
+ // but this is only implicit; there is no connection in the ELF file
+ // between the relocation and the symbol, other than the specification for
+ // the semantics of the relocations. However, the symbol must be included
+ // in our symbol table despite the lack of references to it, since it needs
+ // to be bound during linking for these relocations. For details see
+ // https://sourceware.org/bugzilla/show_bug.cgi?id=22832.
+ MCSymbol *Symbol = Asm.getContext().getOrCreateSymbol("__tls_get_addr");
+ Asm.registerSymbol(*Symbol);
+ auto ELFSymbol = cast<MCSymbolELF>(Symbol);
+ if (!ELFSymbol->isBindingSet()) {
+ ELFSymbol->setBinding(ELF::STB_GLOBAL);
+ ELFSymbol->setExternal(true);
+ }
+ LLVM_FALLTHROUGH;
+ }
case VK_Sparc_TLS_GD_HI22:
case VK_Sparc_TLS_GD_LO10:
case VK_Sparc_TLS_GD_ADD:
- case VK_Sparc_TLS_GD_CALL:
case VK_Sparc_TLS_LDM_HI22:
case VK_Sparc_TLS_LDM_LO10:
case VK_Sparc_TLS_LDM_ADD:
- case VK_Sparc_TLS_LDM_CALL:
case VK_Sparc_TLS_LDO_HIX22:
case VK_Sparc_TLS_LDO_LOX10:
case VK_Sparc_TLS_LDO_ADD:
--- End Message ---
--- Begin Message ---
Source: llvm-toolchain-5.0
Source-Version: 1:5.0.1-3
We believe that the bug you reported is fixed in the latest version of
llvm-toolchain-5.0, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Sylvestre Ledru <[email protected]> (supplier of updated llvm-toolchain-5.0
package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Format: 1.8
Date: Tue, 20 Mar 2018 15:29:03 +0100
Source: llvm-toolchain-5.0
Binary: clang-5.0 clang-tools-5.0 clang-format-5.0 clang-tidy-5.0 clang-5.0-doc
libclang1-5.0 libclang1-5.0-dbg libclang-5.0-dev libclang-common-5.0-dev
libfuzzer-5.0-dev python-clang-5.0 clang-5.0-examples libllvm5.0 libllvm5.0-dbg
llvm-5.0 llvm-5.0-runtime llvm-5.0-dev llvm-5.0-tools llvm-5.0-doc
llvm-5.0-examples lld-5.0 liblld-5.0 liblld-5.0-dev lldb-5.0 liblldb-5.0
liblldb-5.0-dbg python-lldb-5.0 liblldb-5.0-dev
Architecture: source
Version: 1:5.0.1-3
Distribution: unstable
Urgency: medium
Maintainer: LLVM Packaging Team <[email protected]>
Changed-By: Sylvestre Ledru <[email protected]>
Description:
clang-5.0 - C, C++ and Objective-C compiler
clang-5.0-doc - C, C++ and Objective-C compiler - Documentation
clang-5.0-examples - Clang examples
clang-format-5.0 - Tool to format C/C++/Obj-C code
clang-tidy-5.0 - clang-based C++ linter tool
clang-tools-5.0 - clang-based tools for C/C++ developments
libclang-5.0-dev - clang library - Development package
libclang-common-5.0-dev - clang library - Common development package
libclang1-5.0 - C interface to the clang library
libclang1-5.0-dbg - clang library (debug)
libfuzzer-5.0-dev - Library for coverage-guided fuzz testing
liblld-5.0 - LLVM-based linker, library
liblld-5.0-dev - LLVM-based linker, header files
liblldb-5.0 - Next generation, high-performance debugger, library
liblldb-5.0-dbg - Next generation, high-performance debugger, debugging
libraries
liblldb-5.0-dev - Next generation, high-performance debugger, header files
libllvm5.0 - Modular compiler and toolchain technologies, runtime library
libllvm5.0-dbg - Modular compiler and toolchain technologies, debugging
libraries
lld-5.0 - LLVM-based linker
lldb-5.0 - Next generation, high-performance debugger
llvm-5.0 - Modular compiler and toolchain technologies
llvm-5.0-dev - Modular compiler and toolchain technologies, libraries and
header
llvm-5.0-doc - Modular compiler and toolchain technologies, documentation
llvm-5.0-examples - Modular compiler and toolchain technologies, examples
llvm-5.0-runtime - Modular compiler and toolchain technologies, IR interpreter
llvm-5.0-tools - Modular compiler and toolchain technologies, tools
python-clang-5.0 - Clang Python Bindings
python-lldb-5.0 - Next generation, high-performance debugger, python lib
Closes: 889035 890401 891999 893600
Changes:
llvm-toolchain-5.0 (1:5.0.1-3) unstable; urgency=medium
.
* Move the VCS to git.
Many thanks to James Clarke for doing the conversion
* Ignore the test tools/gold/X86/comdat.ll
until https://bugs.llvm.org/show_bug.cgi?id=36166
is fixed.
Will fix the ftbfs on x86
* Create the directory before having the manpages generated
* clang-tidy-5.0: depends on libclang-common-5.0-dev
(Closes: #891999)
* clang-tidy-5.0 also depends on clang-tools-5.0 for, at least
clang-apply-replacements (Closes: #893600)
* Update of the clang-tools-X.Y description
* Fix the libclang1-X.Y.symbols.in file (two spaces)
(Closes: #889035)
.
[ John Paul Adrian Glaubitz ]
* Add proposed upstream patch by James Clarke to add the
missing __tls_get_addr symbol to the symbol table for
TLS calls on SPARC (Closes: #890401)
.
[ James Clarke ]
* Disable LLDB on powerpcspe
Checksums-Sha1:
70323b00f1707066c52d0fd84a536460dc263367 6805 llvm-toolchain-5.0_5.0.1-3.dsc
0c4242debcff99ec594081239f4269e105c76329 71072
llvm-toolchain-5.0_5.0.1-3.debian.tar.xz
59554b7f06aee55840f8e8d140d2db1035538310 20435
llvm-toolchain-5.0_5.0.1-3_amd64.buildinfo
Checksums-Sha256:
a3547e7edafa0680324f89d9b7c8aa3bca63ecb4581322f9733110268d59e664 6805
llvm-toolchain-5.0_5.0.1-3.dsc
6be2d610e478682f2e9b24d7f6c60322e045b1c0544d0ce396e900d78d888721 71072
llvm-toolchain-5.0_5.0.1-3.debian.tar.xz
3ebcf0b2b37e9d13b912ccde8fbba32acf3e3771444c395bb42c467048518dac 20435
llvm-toolchain-5.0_5.0.1-3_amd64.buildinfo
Files:
0690f5cdfc073354eebdcd18108d0406 6805 devel optional
llvm-toolchain-5.0_5.0.1-3.dsc
a66386dcc737e182f603fed651904332 71072 devel optional
llvm-toolchain-5.0_5.0.1-3.debian.tar.xz
36891e935d56904c6fa97d7a4841fda7 20435 devel optional
llvm-toolchain-5.0_5.0.1-3_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEtg21mU05vsTRqVzPfmUo2nUvG+EFAlqxTycACgkQfmUo2nUv
G+G5qw//c9Jd7k/78dgi7oZE76GAx5LCKw0qIKAMaxGxqVf+Dzhmg16hQYU8E7gq
dMLRMz6W8tQ8Ci+CrM/raJ2kA/pf3tmnZ6vrKboa2GPB69LLbtbqJF15//84sAjX
TpNy4W4nnOnXWLgQauavg/GFgTs0G1rfsjxUQcHJzMb0FmO5LbHV43YwYXGAa8sg
p/xgTHfjgDri2F+xeVBL/AEZ2EfNLI8+Ah/5L61//GOY94B4NbRkG7GPYxD7Ws3j
8ulCnFhIrE/WQ9TQN6XA5DTUtq+iDlsxyhZynP3vNkON1Thzf9MTtZMyFlohcmeH
KHGDuyL8Oo1e6mpHMzMrWTgn9iJyTOo7+gXQdhJcaBLuFeBxO0xSeCzWr7OetBaF
vs1cU7ccCgmENLHplke4KeTOx2OTq0uCza1ccLmxtbphBi4SoaxfoJtgnuqHefHY
xlRE4tlnN9gf6v2Z+90x14dF9DH0oHCt07H1hXtOWaqTI6klcaWJ63Zogs4eyrK8
PuZ3YFwgeL5Q0siB6LOeTxfZ8Zf+JskoInvgZuzl/U8406rYXrce8LwT8PU3URKV
SSldRfIdDGU4Ft6oISlS2n87NCghSqhw9DiE9WFq7nC9x26t2nAED4oR3H90PcFO
SZ0ORPZppzfrpOY8cRLvczJmjqhEP0WGaSwCBQL88xD/TWOzvkg=
=Rw/x
-----END PGP SIGNATURE-----
--- End Message ---
